| Age | Commit message (Collapse) | Author |
|---|
|
This wasn't right, if there's actually a backlog of async jobs this
could hold up progress for non-async completions for no good reason.
Just do completions for whatever is present in the processed list,
don't potentially wait.
|
|
This is a preliminary implementaion of an iou-abstracted thread
pool.
Two callbacks are provided to iou_async():
async_cb:
Called by a worker thread and must be carefully written for
concurrent execution.
completion_cb:
Called by iou_run() after a thread has finished with async_cb().
As completion_cb() is called in the iou_run() context, assuming
the caller is always entering iou_run() from the main thread,
it may be viewed as a continuation point for the async work
reentering the serial execution flow.
At this time every iou_new() will create two worker threads. In
the future it may just create a thread per core or something like
that.
|
|
and keep them around on free lists, ops only get actually freed
in iou_free() now.
trivial optimization, but thunk.h needs similar love before any
libiou-heavy program using thunk.h as-is won't have profiles
dominated by malloc/free overheads.
|
|
trivial cleanup to make naming a bit more consistent
|
|
To enable direct use of more liburing helpers, we need to make
the ring struct available to external callers.
The immediate impetus for adding this is registering files...
|
|
This implements a barebones IO-oriented callback scheduler built
atop the new kernel io-uring interface via liburing.
There's not much going on here. The caller must still use
liburing for preparing the SQEs in iou_op_t operations allocated
via iou_op_new(), but that's basically all that's needed from
liburing.
|
