<div>Hi,</div>
<div> </div>
<div>I studied the implementation of Glibc. Below I list some elementary implementation thoughts. Comments are solicited.</div>
<div> </div>
<div>Seems that AIO is not so simple a task as I have thought, especially in that:</div>
<div>(1) AIO requests have different priorities (defined by  aiocb.aio_reqprio)</div>
<div>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).</div>
<div> </div>
<div>(2) aio_cancel should support cancel all the AIO tasks on a FD.</div>
<div>This implies one task queue for each FD, or else this call would be time-consuming.</div>
<div> </div>
<div>(3) Do we need to consider optimization when the worker thread select a task from a task queue.</div>
<div>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.</div>
<div> </div>
<div>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).</div>
<div> </div>
<div>It would be useful to abstract a general task pool that supports various async tasks besides AIO. Such a task pool should include:</div>
<div> </div>
<div>(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).</div>
<div> </div>
<div>(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 the handler)?</div>
<div>For the case of AIO, sharing one handler in the whole pool is enough.</div>
<div> </div>
<div>(3) priority based task scheduling.</div>
<div> </div>
<div>(4) task enqueuing, canceling (matching by specific attributes), status query, blocked waiting.</div>
<div> </div>
<div>(5) resource management/configuration/statistics</div>
<div>Including:</div>
<div>a) max number of worker threads, thread stack size, thread priority;</div>
<div>b) max number of task queues in the pool;</div>
<div>c) max number of tasks in the pool or in each queue;</div>
<div>d) dynamic adjusting of worker threads.</div>
<div> </div>
<div>So, quite a little work to build a good solution ...</div>
<div> </div>
<div>Thanks,</div>
<div>Wei Shen</div>