Re-entrancy

[ekl@sdf.lonestar.org (Evan K. Langlois)]

========================================================================
 hmm, sure?  if we just want IO to halt only processes which are in a
disk IO systemcall (as opposed to `halt _every_ process' like its now...)
then we don't need real multithreaded filesystems yet, and i don't think
the kernel needs much more reentrancy than now like when a process
sleeps for tty IO.  and the SCSI interrupt handler could just reset
its in-service bit and ipl and then addroottimeout()?
========================================================================

If this is possible, I'd REALLY like to see it.  It would help ALOT in
making the OS faster, not to mention practical application.  For example,
recently, all the direct-to-disk recording code I've seen does sector-level
disk manipulation for speed.   This is rediculous, since 16 bit sound,
at 50Khz is 100K/s, for stereo, you get 200K/s.  Just about ANY hard disk
can handle 200K/s, but the real problem is that you can't overlap disk
IO with anything else, so you gotta make the disk IO super-fast so it
doesn't lock up the system too long (at least I guess this is the reason).

Direct-to-disk would get real easy with a nice buffered Minix filesystem
and non-blocking disk IO.  Even if the filesystems weren't multithreaded,
you could still tfork() the main application.  Then a simple circular
buffer of a modest size could be used for direct-to-disk recording.  And
you'd have CPU time left over to move the mouse too!

Actually, I just hate it when the CPU is wasting time polling in a loop
when it could be doing something else.  I don't care what else, anything
else.  I just hate polling!!