[erlang-questions] demonitor

[Richard Carlsson]

Ladislav Lenart wrote:
> I might be wrong but isn't this a "classical" race condition example?
> 
> 1. Monitored process terminates.
> 2. Down message is sent.
> 3. Monitoring process calls demonitor.
> 4. Monitoring process flushes its mailbox for a potential down message
>     which is not there yet.
> 5. Down message arrives and remains in the mailbox "forever".
> 
> Adding of the receive clause does not solve the original problem,
> it just makes it happen less often.

This was once the case, but it is no longer so, as the documentation
for demonitor/1 explains:

''Note: Prior to OTP release R11B (erts version 5.5) erlang:demonitor/1
behaved completely asynchronous, i.e., the monitor was active until the
"demonitor signal" reached the monitored entity. This had one
undesirable effect, though. You could never know when you were
guaranteed not to receive a DOWN message due to the monitor.

Current behavior can be viewed as two combined operations:
asynchronously send a "demonitor signal" to the monitored entity and
ignore any future results of the monitor.''

The current behaviour is:

''Once erlang:demonitor(MonitorRef) has returned it is guaranteed that
no {'DOWN', MonitorRef, _, _, _} message due to the monitor will be
placed in the callers message queue in the future. A {'DOWN',
MonitorRef, _, _, _} message might have been placed in the callers
message queue prior to the call, though.''

    /Richard