Fork watcher will not be called if fork() is invoked in prepare watcher callback.

Marc Lehmann schmorp at schmorp.de
Sat May 3 11:48:30 CEST 2014


On Sat, May 03, 2014 at 10:43:26AM +0800, 李晓岚 <LeeXiaolan+libev at gmail.com> wrote:
> > If you have a convincing use case that couldn't be served by starting an
> > ev_idle watcher and forking from there, we'd be interested in hearing
> > about it :)
> 
> Maybe you know gevent. Gevent use libev as its event loop. When new
> greenlet is spawned, its first run is scheduled in prepare watcher. It
> is make no sense to forbid invocations of fork in new greenlet's first
> run, and ev_idle is also not the right choice.

It makes a lot of sense to forbid invocations of fork in prepare watchers -
basically, something has to give in: prepare watchers are meant to integrate
new event sources, and therefore need to be the last thing before blocking,
so the amount of things that can be done in them is, by necessity, limited.
For example, there cannot be any watcher invocations anymore, which is the
problem here.

You didn't state any reasons on why greenlets have to run inside prepare
watchers, why they would need to fork the event loop, and why idle
watchers wouldn't work for them, so at the moment, everything is in favour
of forbidding event loop forking inside prepare watchers.

In addition, I can't really imagine why these greenlets need to be allowed
to fork, but cannot invoke the event loop. In any case, grenlets will be
limited when they run in prepare watchers, fork or not.

-- 
                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 libev mailing list