Fix signal handler

SF Markus Elfring elfring at
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.
1. A shared array is used there.
2. Would it eventually need to be protected by a mutex (from the multi-threading

> 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 	{
2033 	EV_P = signals [signum - 1].loop;
2037 	#endif
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?

> 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.

> 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?


More information about the libev mailing list