siginfo_t type signal handlers?

Marc Lehmann schmorp at
Thu Jan 31 13:48:28 CET 2008

On Thu, Jan 31, 2008 at 11:37:09AM +0100, libev at wrote:
> At least for the oplock case it would be very difficult to
> do all the necessary handling in the signal handler, so you
> would have to store the data somewhere. If libev would
> provide an interface to feed data (in the case I'm
> interested in it would be a file descriptor) into the event
> loop safely from a signal handler, this should be
> sufficient.

No, it won't, as I know of no way to implement this type of queuing in a
safe way without thread locking or other, more or less horrible things
(ev_async is supposed to allow for multithreading without requiring a
threading library, or for other asynchronous notificaitons, and to do
locking, libev would be required to takle advantage of whjatever mechanism
is appropriate, which it canot know in advance).

So the caller still has to do his own locking, either by temporarily
blocking the signal (which is hard in a thread-safe way), or by using
mutexes or other stuff in both the code calling ev_async_send as well as
its callback.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list