how "synchronous" is exit?

Damien Katz damien_katz@REDACTED
Tue May 30 21:44:04 CEST 2006

Ok, so it appears the code should do something like

Ref = erlang:monitor(process, Pid),
exit(Pid, kill),
{'DOWN', Ref, process, Pid, Reason} ->
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
> and
> (sections 10.6-10.8) for details.
> 	/Richard

More information about the erlang-questions mailing list