Subject: Re: upcalls?
To: Brett Lymn <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 12/10/1999 09:00:56
> >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
- 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.