Feature request: ability to use libeio with multiple event loops

[Marc Lehmann]

On Tue, Dec 20, 2011 at 09:26:20PM +0100, Hongli Lai <hongli at phusion.nl> wrote:
> I know, but that's not what I mean. I'm talking about reentrancy.
> Right now the libeio API assumes that there is one event loop. The

libeio actually makes no assumptions about the existance of an event loop,
or there being only one.

> want_poll callback assumes that I wake up *the* event loop in which I
> am supposed to call eio_poll().

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.

> After studying libeio a bit more I understand how to make it work with
> multiple event loops, but the thing is that I want libeio callbacks to
> be called from the right event loop, namely the requester's event
> loop. I can make this work by passing a reference to the wanted event
> loop as user data to the callbacks, and then have the callbacks call
> another callback on that event loop. But I'll have to do this for
> *every* libeio call so this gets ugly real fast.

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.

> Would you be open to accepting a patch that implements
> EIO_MULTIPLICITY support, similar to EV_MULTIPLICITY? You can disable
> it by default if you like.

Not without a benefit, and I don't see one, neither in performance nor
usability. I feel you want to go through the wall heads-on, no matter the
cost, because you decided the wall is the easiest way to go to the other
side.

From this mail, it seems to be what you might want more is a a second
data member (can be done via EIO_COMMON), or a second wrapper api that
only fills out, but does not submit, requests, so you can make your own
requests (as with libev).

That is certainly something that will benefit from discussion - I am not
happy with the current wrapper API.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\