Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hao!seismo!brl-tgr!tgr!William LeFebvreFrom: William LeFebvre Newsgroups: net.unix-wizards Subject: Re: asynchronous I/O Message-ID: <6316@brl-tgr.ARPA> Date: Tue, 4-Dec-84 00:10:06 EST Article-I.D.: brl-tgr.6316 Posted: Tue Dec 4 00:10:06 1984 Date-Received: Thu, 6-Dec-84 06:37:24 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 27 Mark Sienkiewicz... > Another problem is that if the parent is also doing synchronous I/O, > strange things may happen. The problem I noticed most often was that > if you are blocked for a read, then another process sends you a signal, > your process jumps off to the signal handler, but the read returns -1. That's supposed to happen. The global variable errno will also be set to EINTR, which indicates: An asynchronous signal (such as interrupt or quit), which the user has elected to catch, occurred during a system call. If execution is resumed after processing the signal, it will appear as if the interrupted system call returned this error condition. (This is under BSD, but I'm pretty sure that things are very similar under Bell Unix). If you expect your reads to be interrupted by signals, you should be prepared to handle the condition and take appropriate action (such as calling read again). William LeFebvre Department of Computer Science Rice University