> Can you elaborate on why not?
Yes, of course.
I find that the information "ev_feed_signal ... safe to call this function ...,
including signal handlers or random threads." is not satisfied by the current
implementation at the moment.
Reasons:
1. A shared array is used there.
2. Would it eventually need to be protected by a mutex (from the multi-threading
perspective)?
> Libev currently should be async signal safe -
I try to point out that it is not in a portable way at one place.
> again, if you have any actual evidence to the contrary, we'd be interested
> to hear about them.
Are the following statements really so robust (and therefore without race
conditions) for the discussed use case as you might expect?
2030 ev_feed_signal ...
2031 {
2032 #if EV_MULTIPLICITY
2033 EV_P = signals [signum - 1].loop;
...
2037 #endif
2038
2039 signals [signum - 1].pending = 1;
...
2041 }
> If your suggestions are purely theoretical, I would suggest studying libev
> first to see what it actually dies - if you have any specific questions,
> feel free to ask.
Would you like to consider any secure coding recommendations once again?
https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers
http://cwe.mitre.org/data/definitions/364.html
> Regarding the self-pipe trick, that's exactly what libev currently implements
> (except it uses an eventfd instead of a pipe if available).
I suggest to reuse this technique for a replacement of a global array in a
signal handler.
http://cr.yp.to/docs/selfpipe.html
> Future versions of libev will likely implement details differently
> (e.g. to detect whether the signal was received before or after a fork),
> but even then I don't see why one would chose between different
> implementations.
Will any lock-free approaches become feasible for comparison and selection by a
build configuration?
http://en.wikipedia.org/wiki/Non-blocking_algorithm
Regards,
Markus
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
