[DP-11] unmonitor should remove monitor messages from the mailbox (if any) about distributed-process HOT 13 OPEN

Personally I think this should be an option rather than the default behaviour.

from distributed-process.

There is a PR addressing this issue, and I'm wondering what the purpose of removing the notifications from the mailbox is. Notifications can arrive anytime after unmonitoring, so I don't see how this helps avoiding a message leak.

Moreover, the caller of unmonitor may be interested in handling the notifications after unmonitoring.

from distributed-process.

May you please provide a use case when the caller of unmonitor may be interested in handling monitor notification?
My understanding is that unmonitor is called when you are not interested in the monitored resource anymore? Am I missing something?

from distributed-process.

I have no use case. Just pointing at the fact for others to consider.

from distributed-process.

I think part of the rationale for this is provided the same behaviour as Erlang/OTP. In that case, the unmonitor call flushes (or there's a flushing variant, I forget which is the case) so you won't get unexpected messages in the mailbox. This is particularly important in stateless gen_server and gen_fsm implementations (e.g., what we do in distributed-process-client-server), where an unexpected monitor signal might trigger a shutdown or restart that we don't actually want, and the server loop and message handling/receiving code are hidden from the caller.

from distributed-process.

In that case, I would find less surprising to offer a variant that does the flushing of monitor notifications. Erlang provides more than one variant at least.

from distributed-process.

Yes @facundominguez that's right, and I agree we should offer a variant rather than changing the current behaviour.

from distributed-process.

Erlang does not flush by default, but as @hyperthunk says, gives you the option to. Makes sense to copy Erlang, with an unmonitorFlush variant or somesuch.

from distributed-process.

Well, except that Erlang only kept the non-flush variant by default due to backwards compatibility... http://erlang.org/pipermail/erlang-questions/2008-August/037564.html

from distributed-process.

@mboes you're right, I don't think unmonitor\1 is useful unless the calling process is trying to exit quickly. In that case however, it might've made sense at one time to use the non flushing variant, since you'd otherwise have to trawl a potentially very large mailbox to find the monitor signal you're waiting for before you can exit. Yes, I know that exiting while you've got a lot of mail left to process seems unlikely, but once you're in a supervision tree it becomes far more likely.

Now in Erlang this scenario isn't such a big issue, since selective receive using a monitor ref is heavily optimised. The same isn't true for CH, and we haven't even looked at segregating the mailbox by type to reduce the complexity of selective receive, so I think having a variant that doesn't make the caller wait for the monitor ref to arrive possibly does matter here.

from distributed-process.

Would it work to have unmonitor and unmonitorNoFlush then? unmonitorNoFlush would have the current implementation of unmonitor, and unmonitor would have the implementation given in #252.

from distributed-process.

It's true that there's a potential performance concern here. But i don't think we should choose the semantics based on the details of how things are implemented today. If one wants to unmonitor and exit quickly soon thereafter, can as well just exit with unmonitoring. So I don't see yet how anyone will ever need unmonitorNoFlush, but it's possible (I'd say change the behaviour of unmonitor now, then implement unmonitorNoFlush only once the need does arise for someone in practice).

IOW I vote for merging @VicNumber21's PR #252 without further ado (modulo any review feedback).

from distributed-process.

Yes okay @mboes, I can't really disagree that we shouldn't choose semantics based on implementation details. And stray monitor signals are a pain, so let's merge #252 then, and address the potential /slowness/ of unmonitor as and when we need to.

from distributed-process.