xxx_poll callbacks and multiple event loops

[Paddy Byers]

Hi,

> I'm working on some changes to libuv and trying to support multiple event
> > loops via a single eio thread pool.
>
> Hmm, multiple event loops in a single thread? What would be the use case
> for that?
>
> Or do you plan to also support multiple eio instances, or some other way
> to support multiple submitter/processor threads?
>

I mean multiple libev event loops, each running in a separate thread. The
use case is to be able to run multiple instances of node.js (effectively
multiple isolates) in a single process. The per-request processing that
occurs on pending completions - ie the processing triggered by want_poll -
but be done in the thread associated with the original request.

All of this should be achievable using a single instance of libeio - in
fact my understanding is that there can only be a single instance of libeio
in a single process; there is only one call to eio_init() and all of the
state initialised there is process-wide.

One could in theory pass the eio_req itself to the callback, but I am not
> sure this will lead anywhere helpful - this will still not make requests
> attached to an event loop (whoever calls poll handles the requests).
>

That would be good enough for my use-case - to be able to get the eio_req
back, because I could get back to the event loop from there.

However, the more I think about it, I think I need a want_poll callback
once for each eventloop+thread (which then services all of the events for
that event loop), not just a single callback (which is directed to the
eventloop+thread that happened to be first in the queue). As soon as I have
interleaved pending events belonging to different event loops I think my
change won't work.

Is there a way I can do this in the want_poll callback? to go through all
of the pending requests, work out which ones belong to which event loops
and start a separate watcher for each set?

The ideal thing would be if eio could call my want_poll exactly once for
each distinct poll_data. I'm not sure yet if I can achieve that behaviour
from outside.

I need to think some more. If you've seen this kind of requirement before
or have any other thoughts, it would be good to hear about it.

Thanks - Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20111106/5e86b528/attachment.html>