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 <[email protected]> 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 > [email protected] > http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
