Several questions concerning libeio internals(+)

Marc Lehmann schmorp at schmorp.de
Wed Dec 16 01:58:27 CET 2015


On Tue, Dec 15, 2015 at 08:22:45PM +0300, Nick Zavaritsky <mejedi at gmail.com> wrote:
> I’ve implemented a support for using libeio from multiple threads for tarantool.org. Any interest in this feature?

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?

> (1) What is the purpose of workers list? It is never used besides worker (un)registrations.

Right now, libeio relies on condvars, which are often relatively fair
in which threads they actually wake up. Obviously, it would be better
if "hot" worker threads are reused first, and this is a step towards
implementing that. turned out not to be so easy, but libeio hasn't really
seen a formal release yet either :)

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

> (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?

Well, they are not always identical, but the main concern here is public
vs. private API. Maybe they could be optimised away, but the design in
this area is still in flux.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list