Event-polling after a fork

Marc Lehmann schmorp at schmorp.de
Tue Feb 25 16:39:13 CET 2020

On Mon, Feb 24, 2020 at 10:58:07AM -0500, Felipe Gasper <felipe at felipegasper.com> wrote:
> 	AnyEvent::Util::fork_call() says never to call event-polling functions that call parent callbacks. Is there perhaps a way to clear out AnyEvent’s watchers, or what else have folks done to use event-polling in children spawned from an event-polling parent?

Clearing out AnyEvent watchers (even if it was implementable at all)
wouldn't help, as the problem isn't anyevent but the underlying event

Fork was never designed for this kind of usage as well, and is generally
very limited: for example, it's not possible to safely fork from perl
after something has started threads, at least not portably. This and many
other similar limitations (e.g. modern event polling mechanisms such as
epoll or kqueue) of fork means that controlling your whole process (==
every library, module loaded etc.) so tightly that fork can work is hardly
ever achievable.

The only times you can tighly control your whole environment to make this
work are the common cases of daemonising before starting anything of
consequence, which si the main reason why AnyEvent delays initialising

While AnyEvent::Fork is indeed quite the change in the way of doing
things, the only other alternative that I have seen in the wild is
basically crossing your fingers and hoping corruption and other problems
aren't going to be too bad, i.e. the luck principle.

                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