Several questions concerning libeio internals(+)

[Marc Lehmann]

On Wed, Dec 16, 2015 at 01:46:35PM +0300, Nick Zavaritsky <mejedi at gmail.com> wrote:
> >> 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?

Thread local state is either unportable or slow. in any case, it's overhead.
not knowing what you do and why you do it means I can only speculate of
course.

As for queues, what in the single result queue doesn't work the way you
want?  You can asociate state with each request either by making the
struct larger or using the data member, similarly to libev.

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

No, but the main concern is the cancelled field - accessing it might
non-atomically write the flags field, as C (in the past) made no
guarantees about atomicity between threads.

It could surely be optimised "most everywhere", but if it doesn't hurt,
erring on the correct side is a virtue.

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