> 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
>> resul
On Tuesday 15 December 2015 23:08:39 you wrote:
> 1. When the registered callback fires with the EV_WRITE flag set on the
> third argument, does that mean the port associated with the file descriptor
> is ready to be written to
Correct. However, this "write ready event" is not necessarily triggere
On Wed, Dec 16, 2015 at 01:46:35PM +0300, Nick Zavaritsky
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 correspondin
> 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.
Consider eio_open (const char *path, int flags, mode_t mode, int pri, eio_cb
cb, void *da
On Wed, Dec 16, 2015 at 07:06:18PM +0300, Nick Zavaritsky
wrote:
> Consider eio_open (const char *path, int flags, mode_t mode, int pri, eio_cb
> cb, void *data).
>
> Assume thread A calls eio_open, I want the completion callback to be invoked
> in the same thread.
You need some communication
> 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 par
