On Wed, Dec 21, 2011 at 1:12 AM, Marc Lehmann <schm...@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 work. 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: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands) _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
