On Tue, May 29, 2012 at 04:31:05PM +0400, Denis Bilenko
<denis.bile...@gmail.com> wrote:
> I have a weird test case (attached) where SIGCHLD is not being
> received by libev. I don't quite understand if it's a
Well, thanks for a simple-to-try test program :)
> 1) bug in how I use libev
This one - your test program forks after initialising the default loop,
without calling ev_default_fork.
I added an ev_loop_destroy (EV_DEFAULT) at the end of test_main, and got a
lot longer output, until:
(libev) error creating signal/async pipe: Too many open files
Which is probably a different bug in the test program.
Note that this only works because the fork isn't done while the default
loop exists at the time - if you would fork while the dfeault loop
existed, you'd have to work with ev_default_fork and probably stop all
watchers you inherited form the parent.
Now, the fork business is very unfortunate, but both epoll/kqueue and
pthreads have diminished fork into a state where using an event loop in
both parent ands child has become extreely hard (actually, doing anything
in the child is hard with pthreads).
If you plan to design a new application, it would probably be much easier in
the long run if you either:
a) only use libev in your "worker" processes.
b) fork+exec worker processes, and use libev freely in both (avoiding
epoll if you fork often in the parent).
--
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
