I've heard that there's already a UNIX product to do this:
 "Open LIBR8" (http://www.accelr8.com/)
AST's (Asynch System Traps) , QIO's, mailboxes, etc.

Luke



-----Original Message-----
From: der Mouse [mailto:mouse@Rodents.Montreal.QC.CA]=20
Sent: Monday, 16 December 2002 10:16 AM
To: Emmanuel Dreyfus; port-vax@netbsd.org
Subject: Re: VMS ABI emulation under NetBSD


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