Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.arch
Subject: Re: Async system interface
Message-ID: <1991Feb6.174404.22375@Think.COM>
Date: 6 Feb 91 17:44:04 GMT
References: <3177@crdos1.crd.ge.COM> <13772@lanl.gov> <3181@crdos1.crd.ge.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 30

In article <3181@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>In article <13772@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>| The fact that UNIX is badly designed, doesn't rule out the possibility
>| of other bad systems.  You should never be forced to do a wait system
>| call if what you want is synchronous I/O.  
>The solutions are either a WAIT call, a separate SIO call for blocking
>i/o, or a flag to be supplied on each and every i/o system call.

Another common solution is a settable mode.

On the system I'm most familiar with (Multics), all I/O system calls are
asynchronous (the only time a process ever blocks in the kernel is when it
takes a page fault during a system call).  However, the user-ring I/O
library, which implements the device-independent equivalent to Unix's
read() and write(), normally hides the asynchrony, by internally performing
the wait.  Applications can get an asynchronous interface by using an ioctl
to set non-blocking mode (for devices where it makes sense -- there is no
asynchronous interface to the file system, because it is implemented using
files mapped into virtual memory, and page faults are implemented
synchronously within a process).  The blocking mechanism is based on
general interprocess communications channels, and a process can either
perform a wait call on a channel or request that a signal be generated when
data is written to the channel (this is similar to Unix's select() and
SIGIO, but more general because it can be used independently of I/O).

--
Barry Margolin, Thinking Machines Corp.

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