>>         3) The I/O system is based on a multi-threaded asynchronous
>>            I/O model (the QIO) which could not be emulated in the
>>            current I/O layer.
> Why not?  Could you explain the differencies?

You really need asynch I/O to emulate asynch I/O.

Under VMS, you do a QIO to queue an I/O request.

You can block waiting for the request to complete, either at the time
or later.  Alternatively, you can ask for the request to set an event
flag when it completes (and there are a whole bunch of things that can
be driven off event flags).  Or you can have it deliver...bah, I can't
recall the VMS name for them, but they're basically signal delivery,
only you're not limited to a small-integer number of them with
predefined names.  (A bit like specifying a void (*)(void) with the
request and having it called a la signal delivery when the request
completes.)

Or at least that was what it was back when I used VMS, which admittedly
was a long time ago.  I'd be surprised if any of those have gone away,
though, and even what there was back then would be a mess to do in a
Unix framework.  You'd basically need to invent new calls, with new
semantics, for the new I/O facilities.  (I've seen asynch I/O mentioned
on the lists a few times; it may be suitable as an underlying layer,
though I don't know it well enough to more than speculate.)

/~\ 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