Fix signal handler

Colin McCabe cmccabe at alumni.cmu.edu
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:
http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt

cheers,
Colin


On Sun, Sep 23, 2012 at 6:51 AM, SF Markus Elfring
<elfring at users.sourceforge.net> wrote:
> Hello,
>
> I suggest to look at the implementation of the function "ev_sighandler" again.
> http://cvs.schmorp.de/libev/ev.c?revision=1.448&view=markup#l2029
>
> 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.
> https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers
>
> Does it cause a race condition eventually?
> http://cwe.mitre.org/data/definitions/364.html
>
>
> 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 lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev



More information about the libev mailing list