xxx_poll callbacks and multiple event loops

[Paddy Byers]

Hi,

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

...

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

OK, so this is my idea:

https://github.com/paddybyers/libuv/commit/3ad1de77598e09ed0da19a61cddac7fff137ee02

The key issue I have is that each eio_req is associated with a specific
event loop, and the completion processing for that request can only be
performed in the thread associated with that event loop. This applies when
that thread is associated with a specific v8 isolate or is attached to a
specific java vm, for example.

So I need my want_poll callback to be called on a per-event-loop basis - ie
on the occurrence of the first pending response for that loop. The current
behaviour just gives me a callback on the first occurrence globally; I can
schedule activity when that happens, but I get no further callbacks until
that activity is complete. From the outside (ie as a client of eio) I have
no way of telling that there are also queued responses associated with my
other (idle) event loops.

So my thought is to have a res_queue for each event loop. There is still
only one req_queue, one eio thread pool, and only one condition variable to
wait on. There can still be a default res_queue, but a req can be
associated with a specific res_queue when it is constructed, and the
want_poll and done_poll callbacks are then made with reference to that
queue. In the patch linked above, there is a struct eio_channel which
encapsulates the res_queue and associated user data.

(Unlike my last attempt) this can now run two node instances in separate
threads, each running a file io benchmark and the responses are being
directed to the correct threads for processing.

Does this make sense or am I missing something?

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