> I think libeio already is usable form multiple threads? > >> eio_init() initializes thread local state; a thread gets a private result >> queue + callbacks. There is the single global request queue + a set of >> worker threads. Once a task is complete it moves into the corresponding >> result queue. Embeding model is essentially the same: eio_poll fetches tasks >> from the thread’s private result queue, registered callbacks are invoked >> when the result queue state changes. > > That sounds rather slow and/or unportable - what problem are you trying to > solve that you can't solve at the moment?
We have several threads, each thread runs its own event loop and we want a completed request to return to the issuing thread. Since there is the single result queue in libeio it doesn’t work the way we want. What about separate result queues do you find slow/unportable? >> (2) Why does ALLOC macro lock pool->wrklock? > > The request is shared between threads, and taking the lock addresses > concerns about tearing. There have been layout changes and (most notably), > req->flags is now a sig_atomic_t, but neither change guarantees that it > will work, so it's a "rather be safe than sorry" approach, especially as > it isn't a performance-sensitive place. Isn’t it true that no two threads access a request simultaneously, the cancelled field being the exception? _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
