Unlinking of AF_UNIX sockets

doug at hcsw.org doug at hcsw.org
Wed Jul 4 23:09:41 CEST 2012

That's a very good point. I suppose you would encounter a very similar
issue if the parent had created tmpfile()s which would be unlinked also.
You're right, one of the processes must _exit() or exec() and there's
nothing AnyEvent can do about this. Sorry for the noise.



On Wed, Jul 04, 2012 at 09:25:39PM +0200 or thereabouts, Marc Lehmann wrote:
> On Wed, Jul 04, 2012 at 05:10:11AM +0000, doug at hcsw.org wrote:
> > I was hoping that the parent process could continue
> > listening on the unix socket and accept more connections.
> You cna always create your own listening socket and lsiten on events for
> it (it will become "readable" when there is a connection).
> > Luckily in my case the workers can run POSIX::_exit()
> > when they are done and therefore bypass the guard, but
> > it would be ideal if they were given a chance to flush
> > log buffers and otherwise exit normally.
> If you fork, then either the parent or child has to call _exit or
> equivalent, otherwise buffers might get flushed twice or you run into
> similar problems.
> I don't quite see how you would avoid that - Anyevent isn't your problem
> here, it's just the symptom you saw.
> > Here is a really trivial patch I came up with that
> > solves it for me:
> That patch doesn't really solve anything, because you still have to call
> _exit for other reasons, but it breaks the code for everybody else who
> wants to fork.
> > Having access to the guard so I could cancel it or an
> > option to not install it in the first place would also
> > work fine for me.
> No, it wouldn't. It would only make it less obvious to you that your
> program is buggy.
> You need to cope with the situation the correct way - there is no way to
> track down all destructors and decide when to run them (some of them are
> buried in your libc, for example).
> Unix has a generic mechanism to decide whether to run destructors or not,
> and that is called _exit. It is a bit crude, but it's the best you have.
> -- 
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\

More information about the anyevent mailing list