<div>Hi,</div>
<div> </div>
<div>Just to correct some errors of the previous mail, and extended it with a few more thoughts.</div>
<div><br> </div><span class="gmail_quote">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div><span class="gmail_quote">On 4/3/08, <b class="gmail_sendername">Wei Shen</b> <<a href="mailto:cquark@gmail.com">cquark@gmail.com</a>> wrote:</span></div></blockquote>
<div> </div>
<div>I studied the implementation of Glibc. Below I list some elementary implementation thoughts. Comments are solicited.<br> <br>Seems that AIO is not so simple a task as I have thought, especially in that:<br>(1) should support priority (defined by aiocb.aio_reqprio) based AIO request scheduling<br>
This can be realized by: a) using one task queue for each priority level or linking the tasks having the same priority; b) inserting a new task to the right position in the queue according to its priority (O(lgN) time complexity required).<br>
 <br>(2) aio_cancel should support cancel all the AIO tasks on a FD.<br>This implies a task queue for each FD or another linklist to link the tasks on the same FD, otherwise this call would be time-consuming.<br> <br>(3) Do we need to consider optimization at task selection from a task queue.<br>
For example if there is a task on one FD still in processing, then we consider first tasks of other FDs. Glibc seems to use one worker thread for each FD.<br> <br>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).<br>
 <br>It would be useful to abstract a general task pool that supports various async tasks besides AIO. Such a task pool should include:<br> <br>(1) a number of task queues, and an interface for users to create and locates a task queue - based on a specific attribute or link tasks according to their attributes (e.g. FD attribute of AIO tasks).<br>
 <br>(2) user defined task processing handlers (one hander per pool, per task queue, or per task?), and completion notification per task (maybe better to leave this to the handler)?<br>For the case of AIO, sharing one handler in the whole pool is enough.<br>
 <br>(3) priority based task scheduling.<br> <br>(4) task enqueuing, canceling (matching by specific attributes), status query, blocked waiting.</div>
<div> </div>
<div>In summary, an efficient algorithm and data-structures to support task enqueue/dequeue, scheduling, search and sort, assignment and concurrent processing.<br> <br>(5) resource management/configuration/accounting<br>
Including:<br>a) max number of worker threads, thread stack size, thread priority;<br>b) max number of active task queues in the pool;<br>c) max number of tasks in the pool or in each queue;<br>d) dynamic adjustment of worker threads.<br>
 <br>So, quite a little work to build a good solution ...<br> <br>Thanks,<br>Wei Shen</div></span>