Feature request: ability to use libeio with multiple event loops

[Marc Lehmann]

On Wed, Dec 21, 2011 at 09:21:15PM +0100, Hongli Lai <hongli at phusion.nl> wrote:
> 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:

I am concerned that adding another layer of indirection, with the associated
costs, will make it harder for everyody else.

I can understand that not being able to easily extend the eio_req from
outside is inconvenient.

But when you are embedding, there is EIO_COMMON for this kind of thing.

As for any remainign problems, I'd rather want to solve those than to add
a layer of indirection that solves nothing and complicates everything.

> 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.

Well, nobody forcey you to do that, you can just as well run another
thread that does thta, without any ev_async.

> 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.

Yes, thats an issue, but it's an issue for all users, thats why I mentioned
it might help to separate struct initialisation and submission.

However, with a nice macro, the code can still be easy to write and read:

   eio_open (..., cb, data);

simply becomes:

   eio_open (..., OCB (cb, data));

or some variation thereof. If you have a nice way to bundle state, then
you might not even need the data at all:

   eio_open (..., IOCB (cb));

> Am I understanding this right?

The basics are all right, indeed.

> 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

That might be, but it is a bit like saying "I made this suboptimal design
choice in the beginning, and it's now easier if everything implements
workarounds for that".

> 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?

Not really, because you have to implement it in any case, somehow, in some
way, because if you manage multiple libeios you sitll have to use ev_asynv
to wake up the correct event loop.

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