According to Bill Sommerfeld:
>
>The "aio*" interfaces or similar (perhaps used under the covers by the
>threads package in liu of the regular blocking system calls) might
>allow user-mode threads blocked waiting for I/O to not require a
>kernel thread to be tied up waiting for the I/O completion.
>

Ahhhh, Grasshopper, but the _thread_ scheduler does not know that that
particular thread is blocked hence losing the opportunity of the user
land thread scheduler putting an otherwise idle thread to work,
besides aio* does not work with everything - last I knew you cannot
aio_read from a pipe (this was a while ago though ;-).  With a kernel
upcall the kernel can tell the thread scheduler about the blocking and
the thread scheduler can the switch to another thread, hence improving
the utilisation.  IIRC the normal thing it to have multiple userland
threads mapped to a single kernel thread rather than having a 1:1
user:kernel thread mapping.  The book "UNIX Internals: The New
Frontiers" by Uresh Vahalia goes into some detail about threads and
the usefulness of kernel upcalls even if the information is slightly
dated.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================