how "synchronous" is exit?

[Damien Katz]

Ok, so it appears the code should do something like
this:

Ref = erlang:monitor(process, Pid),
exit(Pid, kill),
receive
{'DOWN', Ref, process, Pid, Reason} ->
  do_something()
end
    
Just to be sure, am I guaranteed the 'DOWN' message
will only be received *after* the whole linked process
tree under Pid is killed?

The reason I ask, I have a process tree that modifies
a file. The file sub-process is in the
process tree.

My code wants to kill that process tree and start a
new one that modifies the same file. Incomplete writes
are not a problems, but race conditions are. I have to
be sure another process isn't still making writes to
the file, so I have to make sure the whole process
tree is dead.

--- Richard Carlsson <richardc@REDACTED> wrote:

> Damien Katz wrote:
> > 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?
> 
> No. Signals (exit/2 sends a signal) are
> asynchronous, just
> like messages. In fact, messages are a special case
> of signals.
> 
> > If not, can anyone tell me a good way to wait on a
> > process tree to die before continuing an action?
> 
> Either using old-school bidirectional process links
> and
> setting the trap_exit process flag in the watching
> process,
> or the more modern, unidirectional process monitors.
> See
>
http://www.erlang.org/doc/doc-5.5/lib/kernel-2.11/doc/html/erlang.html
> and
>
http://www.erlang.org/doc/doc-5.5/doc/reference_manual/processes.html#10.6
> (sections 10.6-10.8) for details.
> 
> 	/Richard
> 
>