Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: catching signals while writing to a tty-line
Message-ID: <6405@brl-smoke.ARPA>
Date: Fri, 4-Sep-87 12:23:54 EDT
Article-I.D.: brl-smok.6405
Posted: Fri Sep  4 12:23:54 1987
Date-Received: Sat, 5-Sep-87 18:07:15 EDT
References: <589@euraiv1.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23
Keywords: signal;slow i/o

In article <589@euraiv1.UUCP> aiv@euraiv1.UUCP (Eelco van Asperen) writes:
>	the calling process with errno set to EINTR."
>The problem is of course to detect the number of characters that has
>already been written so that we don't send chars twice or not at all.

You can't.  It's a serious design botch.

4.nBSD (n >= 2) has the opposite problem: it restarts the interrupted
I/O so some characters are transmitted twice (and you can't tell how
many).

This is one of those things that could have been fixed in IEEE 1003.1
(POSIX), without hurting any application (how could it hurt to get
correct information in such a case?).  However, as of Draft 11, POSIX
has waffled on this, allowing either -1 (EINTR) or correct byte count
for the partial transfer to be returned.  This is the sort of thing
that I find unacceptable in a STANDARD.  It undoubtedly arose because
some vendor thinks that their POSIX-compatible write() will have to
be backward-compatible with their current broken write(); of course
both old and new behavior could be provided by vendors who have this
concern, but either that hasn't occurred to them, or else they would
rather have a serious semantic botch than do the work necessary to
fix it.  I am disgusted by this.