Closed NOMORECOFFEE closed 8 years ago
I'm ok with that, that's not being handled by rpc:call either!
It isn't right. rpc:call
return {badrpc,{'EXIT',killed}}
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
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?
Hi. If we don't set call_receive_timeout
into infintity
, then everything will be fine.
Or we can use another middleman process here and don't touch the acceptor state.
@priestjim I wanted to warn only about spawn_link/kill.
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)
For example
gen_rpc:call(<not_local_node>, timer, kill_after, [0])