search

priestjim / gen_rpc

A scalable RPC library for Erlang-VM based languages
Apache License 2.0
221 stars 81 forks source link

try ... cacth never handle erlang:kill #58

Closed NOMORECOFFEE closed 8 years ago

NOMORECOFFEE commented 8 years ago

For example gen_rpc:call(<not_local_node>, timer, kill_after, [0])

priestjim commented 8 years ago

I'm ok with that, that's not being handled by rpc:call either!

NOMORECOFFEE commented 8 years ago

It isn't right. rpc:call return {badrpc,{'EXIT',killed}}

NOMORECOFFEE commented 8 years ago

gen_rpc should use like in rpc https://github.com/erlang/otp/blob/maint/lib/kernel/src/rpc.erl#L200 or use middleman process https://github.com/erlang/otp/blob/maint/lib/kernel/src/rpc.erl#L338

priestjim commented 8 years ago

This requires some pretty steep changes to deal with, including keeping track of workers, which creates garbage in the acceptor state and extra messages. Do you believe it's worth it?

NOMORECOFFEE commented 8 years ago

Hi. If we don't set call_receive_timeout into infintity, then everything will be fine.

NOMORECOFFEE commented 8 years ago

Or we can use another middleman process here and don't touch the acceptor state.

NOMORECOFFEE commented 8 years ago

@priestjim I wanted to warn only about spawn_link/kill.

priestjim commented 8 years ago

This is a real issue but affects very few of real world cases (making RPC calls on functions that use messages and self() such as timer:kill_after). I am thinking about making a special "call" case with receive timeout infinity and handle it with a middleman process or with trapping exits but that will render reply inconsistencies (call with infinity will return killed, call with timeout will return timeout)