I wrote, yesterday,

> My pseudo-disk driver hung on me today.

followed by a description of how delayed buffer flushing caused the
control process to deadlock against itself.  I ended with

> I could, I suppose, buffer the data and mark the I/O as done before
> speaking with the control process, queueing that for later, but
> that's rather ugly and potentially needs effectively unlimited buffer
> space.  But it ought to at least work...maybe I should just think of
> it as "first make it work, then make it better".

I've now implemented this, but do it only when the I/O is being done by
a process that has a file descriptor open on the control device.
Obviously, this is suboptimal, because (a) it kludges around the
problem rather than fixing it and (b) it requires scanning the open
file table of every process that does I/O - which, because any process
can end up provoking dirty buffer flushes, can mean any process.  It
also means that in this circumstance the actual I/O is delayed until
the _next_ time someone attempts I/O on the pseudo-disk.  It also still
risks deadlock if the control process ever blocks waiting for another
process to do anything.

Its only redeeming feature is that it kept the machine from hanging.

I did record the b_flags values from the affected buffers.  So far,
it's always been 0x1000015, B_WRITEINPROG|B_BUSY|B_ASYNC|B_AGE.  Now
I'm presently not paying attention to B_ASYNC, something I intend to
change - but can I count on this?  Will any writes by random processes,
processes not explicitly doing I/O to the pseudo-disk, always have
B_ASYNC set?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B