[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
POSIX Async IO (GSoC)
- Date: Thu, 3 Apr 2008 00:14:12 +0800
- From: cquark at gmail.com (Wei Shen)
- Subject: POSIX Async IO (GSoC)
I studied the implementation of Glibc. Below I list some elementary
implementation thoughts. Comments are solicited.
Seems that AIO is not so simple a task as I have thought, especially in
(1) AIO requests have different priorities (defined by aiocb.aio_reqprio)
This can be realized by: a) using one task queue for each priority; or b)
inserting a new task to the right position in the queue according to its
priority (O(lgN) time complexity required).
(2) aio_cancel should support cancel all the AIO tasks on a FD.
This implies one task queue for each FD, or else this call would be
(3) Do we need to consider optimization when the worker thread select a task
from a task queue.
For example if there is a task belongs to one FD still in processing, then
we consider tasks of other FDs first. Glibc seems to use one worker thread
for each FD.
We also need to support two kinds of notification - signal (SIGEV_SIGNAL)
and callback (SIGEV_THREAD), immediate stutus query (aio_error), and
blocking on an AIO task (aio_suspend).
It would be useful to abstract a general task pool that supports various
async tasks besides AIO. Such a task pool should include:
(1) a number of task queues, and an interface for users to create and
locates a task queue based on a specific attribute of tasks (e.g. FD
attribute of AIO tasks).
(2) user defined task processing handler (one hander per pool or per task
queue or per task?), and callback per task (maybe better to leave this to
For the case of AIO, sharing one handler in the whole pool is enough.
(3) priority based task scheduling.
(4) task enqueuing, canceling (matching by specific attributes), status
query, blocked waiting.
(5) resource management/configuration/statistics
a) max number of worker threads, thread stack size, thread priority;
b) max number of task queues in the pool;
c) max number of tasks in the pool or in each queue;
d) dynamic adjusting of worker threads.
So, quite a little work to build a good solution ...
-------------- next part --------------
An HTML attachment was scrubbed...