In message <20070301191956.62F7A233C4C@mail.linija.org>,
"Mindaugas R." writes:

>Jason Thorpe <thorpej@shagadelic.org> wrote:
>> 
>> On Mar 1, 2007, at 10:22 AM, jonathan@dsg.stanford.edu wrote:
>> 
>> > Well, the typical way to implement AIO is to have a pool of kernel
>> > threads. Grab a kernel thread, issue the i/o, using the kernel thread
>> > as the thread which blocks until the I/O is complete.  Then the kernel
>> > thread posts completion to the AIO subsystem, which passes appropriate
>> > status, signal info, etc. to the requesting thread.  Hmmmm,  
>> > continuations :-/.
>> 
>> ...and that's an awful way to do it considering how all of the  
>> underlying primitives that those blocking APIs use are asynchronous.
>Well, I am implementing this model, right now. What would you suggest as a
>long-time solution?

Just personally, I'd say a kthread-based AIO is far, far better than
no AIO at all.  Provided we get the userland API right, we can rework
the internals later.

I don't know what Jason would suggest, but kcont(9) was intended for
just such purposes. Bill S-S has also suggested a continuation model;
tho' I don't know if Bill meant kcont(9) specifically, or a
continuation-passing style, independent of kcont(9).

Now that -current requires generic-softints on all platforms, we could
(if we choose) easily resuscitate kcont and make it always-present,
rather than an option...