> You need some communications mechanism for your threads - that's outside > the scope of libeio, really. > >> However since there’s the single result queue, it’s impossible to route the >> completed request to the particular thread. > > If it's impossible to route completed requests to the particular thread > that wants the result, then nothing in libeio can fix that, since it is
I believe it will be useful if libeio routed the request back to the issuer thread. It is technically possible to build another layer on top of libeio to process the result queue and to route results to particular threads. This approach has serious drawbacks: * you can’t get request pointers from eio_poll(), even more: the function destroys requests, hence in order to route requests somewhere you have to duplicate them; * you have to route requests from the completion callback; original callback has to be remembered somehow, and all functions like eio_open have to be wrapped; * it is inefficient since a request has to get from a worker thread to the dispatcher thread and then to the final destination. If you consider this feature to be out of scope for libeio, I am fine with that. _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
