In message <20070301191956.62F7A233C4C (AT) mail (DOT) linija.org>,
"Mindaugas R." writes:

>Jason Thorpe <thorpej (AT) shagadelic (DOT) orgwrote:
>
>Mar 1, 2007, at 10:22 AM, jonathan (AT) dsg (DOT) stanford.edu wrote:
>
>Well, the typical way to implement AI 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/ is complete. Then the kernel
>thread posts completion to the AI 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 AI is far, far better than
no AI 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