> >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,

Be careful who you call grasshopper, Grasshopper.  I've been doing
threads-related work on UNIX and other OS's for over ten years.

The userland thread library could interpose versions of read() and
write() which:
	- do an aio_read() or aio_write() to post an I/O request.
	- do appropriate bookkeeping to record the async request where the
	  aio i/o completion handler could deal.
	- do a pthread_cond_sleep() to put the userland thread to
	  sleep purely in userland without needing a kernel thread to
	  hold its context; 
	- the userland thread scheduler can then attempt to find
	  something better to do with the rest of the timeslice.

When the notification for the I/O completion comes in (possibly by a
queued sigevent, another POSIX API not yet NetBSD), the completion
handler can then do a pthread_cond_signal() to wake up the thread
waiting for that i/o completion, informing the userland scheduler that
it's runnable again.

> besides aio* does not work with everything - last I knew you cannot
> aio_read from a pipe (this was a while ago though ;-).  

Last I knew, NetBSD didn't support the posix aio* calls yet.  When we
do support them, we can make them work for all types of descriptors.

				- Bill