On Tue, May 29, 2012 at 05:29:20PM +0200, Gabriel Kerneis
<kern...@pps.jussieu.fr> wrote:
> I do not understand what you mean here, probably because I never tried to mix
> fork, pthreads and epoll in a single program. Could you please provide some
> more details,
epoll: epoll file descriptors are available in the child, and events are
delivered to both, even for file descriptors that are closed in one of the
processes. since you need an fd to remove fds from an epoll set, you can't
remove that fd (libev uses a heuristic to detetc this case and then recreates
the whole epoll ste, which cna be slow)
kqueue: the kqueue fd is close'd during fork (yes, missing :), or disabled
(yes, fd is still there) and event libraries cannot reallx distinguish
between the cases. this is not as bad as epoll, but still requires special
fork support from event libraries.
pthreads: after pthread_create, the child environment after fork is
as restricted as in a signal handler, i.e. after fork, you cannot use
malloc/printf or anything else thats unsafe in a signal handler.
the result of this is that it's no fun at all to use fork for
multiprocessing.
(not that fork ever was so good for multiprocessing when doing something
more complicated than a preforked server).
--
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
