libev's child reaping breaks system() function

Robin Haberkorn rh at
Fri Aug 27 12:35:46 CEST 2010

> multi-threading itself breaks a lot of stuff (fork for example) in
> subtle
> ways. this issue is not really something that libev can do something
> about.
libev can easily do something about it: make child reaping more
flexible by allowing SIGCHLD ev_signals.
Also system() isn't broken by multithreading - it works fine as
long as only one thread's executing system() at a time.
It's the child reaping that breaks it. It will also break
*any* other waitpid() occurrence by resulting in race
conditions. waitpid() is even defined as thread-safe.
> the solution is to not use system then, just as any other funciton
> that
> causes problems when threading.
ok, suppose I won't use system() anymore. The thing is if I
would rewrite it on my own, I would have to do it very
similar to the libc implementation. As a result, I would
experience the same kind of race condition.
Using an event-based child termination handling while keeping
the system()-like function synchronous/blocking would
introduce an unnecessary synchronization overhead
(like adding ev_childs to the default loop belonging to
another thread and using condition variables) as well
as other problems.
Making the mechanism asynchronous/non-blocking, would
require major code refactoring and make conceptually
simple code dis-proportionally harder to read.

> > That doesn't seem to be pretty much straight-forward.
> > IMHO, I could live without the ev_child watcher at all but
> > I would be happy with a clean way to use ev_signal to process
> Don't use system or multihreading - posix is harsh, and multithreading
> imposes rather draconic limitations on a program. not much that can be
> doen about it. it's a pain in the ass, but libev can only use what
> posix
> offers.

I don't see why this shouldn't be possible (and as I
pointed out, it is already using a custom signal handler and
async watcher).
Is there a design decision that says: either be content
with libev's default child reaping or don't use any event-based
child reaping approach at all?

------------------ managed broadband access ------------------

Travelping GmbH               phone:           +49-391-8190990
Roentgenstr. 13               fax:           +49-391-819099299
D-39108 Magdeburg             email:       info at
GERMANY                       web:

Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780

More information about the libev mailing list