Nick, I am sure these changes will be able to help others in the future. I hope you are willing to publish them as a Gist or something (along with an explicit license statement) in case they do not make it into the libeio core.
Thanks, Chris On Tue, Dec 15, 2015 at 12:22 PM, Nick Zavaritsky <[email protected]> wrote: > Hi! > > I’ve implemented a support for using libeio from multiple threads for > tarantool.org. Any interest in this feature? > > 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. > > It would be great if you answer several questions about libeio internals. > > (1) What is the purpose of workers list? It is never used besides worker > (un)registrations. > > (2) Why does ALLOC macro lock pool->wrklock? > > (3) Several pool attributes seem redundant. For instance, nready is > essentially req_queue.size and npending==res_queue.size. They aren’t > redundant, are they? > > Regards. > _______________________________________________ > libev mailing list > [email protected] > http://lists.schmorp.de/mailman/listinfo/libev _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
