async I/O

[Barry Margolin]

In article <20718 at stealth.acf.nyu.edu> brnstnd at stealth.acf.nyu.edu (Dan Bernstein) writes:
>I very much agree with Peter. The basic I/O calls should be asynchronous:
...
>Exactly. read() and write() would be short library routines.

Watch out, this is how Multics does it.  Remember, Unix is supposed to be a
castrated Multics :-)

On Multics, the only system call that causes the process to block is
hcs_$block, which is similar to select().  All I/O system calls are
asynchronous (file access is done using memory mapping and paging, so it
isn't included).  These are hidden away in library routines (called I/O
modules) which implement device-independent, I/O (similar to Unix read(),
write(), etc.).  Since the underlying mechanism is asynchronous, I/O
modules can provide synchronous and asynchronous modes.

When doing asynchronous writes, the I/O module returns the count of the
number of characters written.  The caller can then advance his buffer
pointer that many characters into his output buffer, wait for the device to
be ready to accept more data, and then try to write the rest of the buffer;
this is iterated until the entire buffer is taken.  The terminal driver
also provides an all-or-nothing interface, for use by applications that
write escape sequences (to guarantee that process interrupts don't cause
partial escape sequences to be written); this is just like the normal
interface, but acts as if the kernel's buffer is full unless it has enough
room for the entire string being written (even a normal write call can
return "0 characters written", if other processes fill up the kernel
buffers before this process gets around to making the write call).

--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar