Thanks to gevent expert Denis' clarification.
On Sat, May 3, 2014 at 5:48 PM, Marc Lehmann <schm...@schmorp.de> wrote:
>
> 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.
In gevent, prepare watcher really do mean some other events which
indicate some greenlets are ready to run.
> 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.
Gevent is just a library, the greenlets are user code which is not
under control, so users can do anything they want there. A greenlet is
a coroutine, it is weird some part of greenlet can fork, but other
part can do. The following snippet iilustrate, it is python code:
def func():
someFunctionDoNotSwitchOver() # some code here is running in
# prepared watcher callback,
# so fork is forbidden.
result = doNetworkIO() # this code will make current greenlet
# to setup a io
watcher and switch to
# other greenlet.
doResult() # this code will be
runing in io watcher
# callback, so fork
is allowed.
Very strange, huh. To libev, the strange is some watch can fork, but some can't.
> 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.
To fork, maybe we just want to save the snapshot of the memory to
avoid data inconsistent. Because saving process invokes io operation
which can make the saving greenlet to switch over and other greenlet
makes change to memory. Maybe other strange reasons to fork, whatever.
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
