Marc Lehmann schmorp at
Tue Jan 29 14:36:43 CET 2008

On Mon, Jan 28, 2008 at 01:22:42PM -0700, Tony Arcieri <tony at> wrote:
> In fact, I could envisage that this functionality (signaling a loop
> > asynchronously) could become part of libev proper if there is demand, as
> > libev already has to handle asynchronous signals at leats in one loop
> > and therefore needs the mechanism already (and that way it could e.g. be
> > optimised by using an eventfd or other os-specific means).
> >
> Something like this would be extremely useful for sending asynchronous
> messages across threads.  Rubinius does something like it already, and I'll
> be adding something like it to Revactor soon.  If you did implement some
> sort of cross-thread signal watcher I'd probably end up using it.

Ok, counted, lets see if I can find time.

The proposed interface would be something like:

   struct ev_async {
      // nothing to see, except maybe a
      sig_atomic_t signal;
      // (where we assume that sig_atomic_t is also threadsafe :)

   void ev_async_send (ev_async *w, sig_atomic_t signal);

the async_send would be callable, well, asynchronously. the problem is
getting it fast (as in O(1)), but I guess a O(n) solution in the number of
async watchers might do (and could always be improved).

It would also avoid any queueing issues by not supporting it, so signaling
a aignal n times might result in <= n invocations (and maybe this is why
the sig_atomic_t member might not be there).

Also, the uer would be responsible to only run ev_async_send on started
watchers etc. etc.

all that would piggypack nicely on top of the existing signal handling.

feedback from people on this would be nice.

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

More information about the libev mailing list