Sorry for the later answer!
On Sun, May 04, 2014 at 10:35:31AM +0800, 李晓岚 <leexiaolan+li...@gmail.com>
wrote:
> 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.
Right, the same is true for not being able to enter the event loop, I
would guess. That kind of strenghtenes the case for not running them in
prepare watchers.
> Very strange, huh. To libev, the strange is some watch can fork, but some
> can't.
It's only strange if you don't understand the reasons why it is so -
every watcher type is different. Since things can be very complex and you
shouldn't have to bother, these limitations need to be documented (and
mostly are, but this one slipped through our attention).
> > 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.
There is no prohibition on fork per-se, just on forking the event loop.
Forking is also one of the slowest operations you have these days (virtual
memory needs to be copied, which is why we have vfork for example) and
recreating the kernel state for libev is also quite costly - have you
figured the cost of, say, 10 mio cpu cycles for fork() and 10000 extra
syscalls for libev in your calculations?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
