Unlinking of AF_UNIX sockets

Marc Lehmann schmorp at schmorp.de
Wed Jul 4 21:25:39 CEST 2012

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