haskell-distributed
[DP-11] unmonitor should remove monitor messages from the mailbox (if any)
Personally I think this should be an option rather than the default behaviour.
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.
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?
I have no use case. Just pointing at the fact for others to consider.
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.
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.
Yes @facundominguez that's right, and I agree we should offer a variant rather than changing the current behaviour.
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.
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
@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.
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.
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).
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.