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
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
