[erlang-questions] msg mailbox and gen_svr shutdown
Thu May 10 22:37:55 CEST 2012
I had the same problem with Cowboy recently, really ought to file an issue
to at least fix the docs for that.
For my app I wanted to implement a graceful shutdown that stopped accepting
new connections but allowed existing requests to finish. The waiting part I
implemented by adding a gproc local property to the workers that I wanted
to wait for and then monitoring them.
Looks like this:
On Thu, May 10, 2012 at 2:53 AM, Paweł Peregud <>wrote:
> I was having fun with supervisors yesterday (Cowboy seems to fail to
> fulfill the promise of not killing request processes after listener
> removal) and I have an example. I've only investigated the case when
> supervisor is killed, so YMMV. Example code is attached. You may modify it
> to check the behavior in your case.
> Start supervisor tree with exp_sup_sup:start_link(). Execute test with
> exp_sup_sup:test() and exp_sup_sup:test_simple().
> In case of dying supervisor the answer is "no, it does not".
> When supervisor dies, your process is killed as via link mechanism, so it
> may leave some unprocessed messages in inbox. To make sure that every
> delivered message is served, you need to add process_flag(trap_exit, true).
> Messages that are sent after the moment when supervisor dies are not
> Best regards,
> On May 9, 2012 11:06 AM, "Andy Richards" <>
>> I can't seem to see any confirmation in the documentation so was
>> wondering if anyone could confirm if messages are still sent to a
>> supervised gen_svr following a shutdown message?
>> If so how do I cleanly shutdown my gen_svr without loosing messages? I
>> read in the supervisor child spec that a shutdown can be set to infinity
>> which i hoped would allow me to process the msg's in my mailbox but if I do
>> this will my module continue to receive messages from other processes? Is
>> my approach flawed and if so what other ways are there to cleanly shutting
>> down my gen_svr without loosing messages?
>> Many thanks,
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions