On Thu, 01 Mar 2007 10:22:33 -0800
jonathan@dsg.stanford.edu wrote:

> But there are apps (or programming styles) where it's incredibly
> useful to find the point at which an I/O read is going to block.

Exactly, and this would be especially suited for latency-critical
single-threaded applications using non-blocking I/O with kqueue for
sockets, but which also need to do some disk I/O occasionally...  And as
previously mentionned this might enhance the efficiency of an M:N
model's userland scheduler.

> Right now, how much can I read() without blocking?  One byte? 512? 1k?
> 8K? 64k?  1M?  I've often wanted a way to do a kqueue-like request to
> ask that.  Asking for writes would be even better, but that brings up
> all sorts of overcommit issues. (buffer space avaiable now may not be
> available by the time the requesting process tries to write() into it).

Hmm maybe if there was a per-LWP buffer for output?

> 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 :-/

If kernel threads are really needed for this, it makes me wonder if a
pool of LWPs handled by a userland M:N scheduler especially for disk I/O
would be as efficient...  wouldn't there be a way for the kernel to do
this more asynchroneously without the need for a kthread per blocking
I/O call?  Or would this require a multithreading revamp of various
subsystems? 

Thanks,
Matt