Marc Lehmann schmorp at
Wed Jan 30 13:53:55 CET 2008

On Tue, Jan 29, 2008 at 02:59:15PM -0800, Eric Brown <yogieric.list at> wrote:
> That's a good idea. But if thread A (also loop A) decides to release its
> accept loop for hand off to thread B/loop B, I'll have to stop its watcher
> on loop A and add a watcher on loop B -- all from thread A (unless I use
> pipes, etc). Thus I think I'd have to add locking around all libev calls (or
> use pipes, etc)... or am I overlooking something?

No, pipes are locking-free in user-space, or, viewed differently, pipes are
already locks.

In fact, you cannot sensibly lock libev at all, because your lock has to
go around ev_loop as well, and this you will be effectviely locked all the

> Or perhaps that's what you're saying here? Move the accept watcher around
> and use pipes to tell the next loop to take ownership?

Wether you move the same watcher around or different ones makes no
difference, the problem is the moving around bit, yes. Moving around a single
watcher is as complicated (even more complicated) then enabling/disabling the
watcher in eahc loop separately.

The key is to only do watche roperations in the loop owning the watcher,
using other means to communicate that they should do so.

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

More information about the libev mailing list