Feature request: ability to use libeio with multiple event loops

Hongli Lai hongli at phusion.nl
Wed Dec 21 21:21:15 CET 2011

On Wed, Dec 21, 2011 at 1:12 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> libeio actually makes no assumptions about the existance of an event loop,
> or there being only one.
> ...
> well, I pointed out a way to you how to work with multiple event loops, so
> I am not sure why you write that: it is not true.
> ...
> Since all the request structures are the same size, you could simply append
> your data fields to the structure.
> Alternatively, if you want to use the wrapper api (which allocates the
> request structure for you), you can use the normal method via data. A bit
> of macor magic might work wonders.

Okay so maybe I was being too vague with my wording. I didn't
literally mean that libeio assumes a single event loop, I meant that
the way libeio is written right now would have that effect unless I
spent a lot of effort working around it.

I know that it's *possible* to make it work with the way libeio is
right now. What I'm concerned about is that it takes me a huge amount
of boilerplate code to do so. Consider all these steps:

1. Initialize libeio with a want_poll callback that wakes up some
arbitrary event loop in my program through the use of ev_async. Have a
separate ev_async object per event loop.
2. The ev_async callback is to call eio_poll().
3. Call eio_open(..., open_callback, data), where 'data' is a struct
which is to contain: 1) a pointer to the calling thread's event loop
and 2) an ev_async object that's associated with that event loop.
4. open_callback will eventually be called, but it will be called from
some arbitrary event loop, not necessarily the event loop that
originally called eio_open(). So open_callback is to wake up the
original event loop by sending a signal to the ev_async object as
referenced by 'data'.
5. The aforementioned ev_async's object's callback is called from the
event loop that originally called eio_open(), so it can finally do the

Am I understanding this right?

I would like to avoid step 4. It would seem so much easier and more
natural for me if I can just have a different "instance" of libeio for
each event loop, then I don't have to worry about this problem
anymore: libeio callbacks will then always be called from the event
loop that I expect it to, as long as I pass the correct eio_context
object. Don't you see avoiding step 4 as a benefit?

- Hongli
Phusion | Ruby & Rails deployment, scaling and tuning solutions

Web: http://www.phusion.nl/
E-mail: info at phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

More information about the libev mailing list