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!steve@anasazi.uucp From: steve@anasazi.uucp Newsgroups: net.unix-wizards Subject: proper recovery from EINTR Message-ID: <6568@brl-tgr.ARPA> Date: Sun, 9-Dec-84 17:59:38 EST Article-I.D.: brl-tgr.6568 Posted: Sun Dec 9 17:59:38 1984 Date-Received: Tue, 11-Dec-84 04:49:44 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 64 The folks here at Anasazi have been puzzling over this one for a while. Any pointers to a solution, or even an informed discussion, would be appreciated. The problem is to write two functions v_read and v_write which behave like the UNIX system calls read and write, except that they work "properly" on a slow device while (unrelated) signals are being caught. Specifically, assume that the file descriptor may denote a "slow" device such as a terminal, and various signals may be set up to be caught, and other processes may be doing kill's on those signals at random times. Despite this, in cases where read and write would return -1 with errno = EINTR, v_read and v_write are required to transfer all n bytes correctly, in the correct order, with no omissions or duplications, and return the number of bytes n that were transferred (assuming no real error like EOF occurred). Here is a first cut for v_read (v_write is similar): v_read(fd, buf, n) int fd, n; char *buf; { register int i; register char *cp; int serrno; serrno = errno; cp = buf; i = 0; while (i < n) switch (read(fd, cp, 1)) { case -1: if (errno != EINTR) return -1; break; case 0: errno = serrno; return i; case 1: cp++; i++; break; default: abort(); } errno = serrno; return n; } Some obvious questions: If you do a read system call with a length > 1, and EINTR occurs, is there a way to find out how many bytes were actually transferred? Even in the length = 1 case, can you really be sure that the one byte was not transferred? Finally, is there a way to speed this up, and avoid n system calls to do the read? Thanks for any help. Stephen E. F. Villee (decvax!noao!terak!anasazi!steve) International Anasazi, Inc. 2219 East University Drive Phoenix, Arizona 85034 (602) 275-0302