Fix signal handler

Colin McCabe cmccabe at
Sun Sep 23 23:43:18 CEST 2012

If you check the header file, you find that ev_feed_signal_event is
writing to a variable of type EV_ATOMIC_T, which turns out to be a
typedef for sig_atomic_t.

So it's "almost" standards-compliant, except for the fact that
technically the standard says you must use volatile, and libev uses
memory barriers instead.

I think memory barriers have been added to C++11, but they haven't
gotten around to formally adding them to C yet.  Or something like
that-- I haven't been following the standards that closely.

The reality is, volatile is stupid, and most advanced C users use
memory barriers instead.  Linus and some other kernel hackers wrote a
document explaining why:


On Sun, Sep 23, 2012 at 6:51 AM, SF Markus Elfring
<elfring at> wrote:
> Hello,
> I suggest to look at the implementation of the function "ev_sighandler" again.
> It calls the function "ev_feed_signal" which works with the global array
> "signals". I find that the use of this data type is not async-signal-safe for a
> strictly conforming program.
> Does it cause a race condition eventually?
> Would you like to look for alternative interfaces which will enable the desired
> data exchange in a safe and robust way?
> Regards,
> Markus
> _______________________________________________
> libev mailing list
> libev at

More information about the libev mailing list