Fix signal handler

SF Markus Elfring elfring at users.sourceforge.net
Mon Sep 24 12:00:23 CEST 2012


> 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



More information about the libev mailing list