how "synchronous" is exit?

Ulf Wiger (AL/EAB) ulf.wiger@REDACTED
Wed May 31 00:56:47 CEST 2006


Richard replied that it isn't synchronous at all.

Even for exit(Pid, kill), Pid will be scheduled in order to handle the
exit. When the reason is 'kill', the handling will never involve user
code in Pid.

In the following example, you can see the timing issues:

Eshell V5.4.12  (abort with ^G)
1> process_flag(trap_exit, true).
false
2> GotExit = fun(P) -> receive {'EXIT',P,_} -> true after 0 -> false end
end.
#Fun<erl_eval.6.10732646>
3> Pid = spawn_link(fun() -> timer:sleep(timer:minutes(10)) end).
<0.34.0>
4> exit(Pid,kill), {erlang:is_process_alive(Pid), GotExit(Pid)}.
{false,true}
5> 
5> process_flag(priority,high).
normal
6> Pid2 = spawn_link(fun() -> timer:sleep(timer:minutes(10)) end).
<0.38.0>
7> exit(Pid2,kill), {erlang:is_process_alive(Pid2), GotExit(Pid2)}.
{false,false}
8> GotExit(Pid2).
true 

That is, is_process_alive(P) will immediately return false, if the
process P is dead or has been scheduled for termination, but you can not
be sure that exit messages have been propagated, even to the process
that killed P.

It is *very* unwise to make assumptions in this realm, for the sake of
speed. My first version of proc_reg in jungerl did this - even making
use of ets:insert_new() and other tricks in order to ensure timing
safety. It was all for naught, as a session with QuickCheck mercilessly
illustrated. We found a timing bug that was both very difficult to even
comprehend, and practically impossible to fix without rendering all
optimizations useless.

BR,
Ulf W

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of Damien Katz
> Sent: den 30 maj 2006 01:57
> To: erlang-questions@REDACTED
> Subject: how "synchronous" is exit?
> 
> When issuing an exit(Pid, kill) to a another process, is 
> there any guarantee that the process, and all its linked 
> child processes, are dead before continuing?
> 
> If not, can anyone tell me a good way to wait on a process 
> tree to die before continuing an action?
> 



More information about the erlang-questions mailing list