Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.unix.questions
Subject: Re: catching signals while writing to a tty-line
Message-ID: <5740013@hpfcdc.HP.COM>
Date: Fri, 4-Sep-87 19:44:25 EDT
Article-I.D.: hpfcdc.5740013
Posted: Fri Sep  4 19:44:25 1987
Date-Received: Thu, 10-Sep-87 00:37:37 EDT
References: <589@euraiv1.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 26

> >	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.

I'll agree with the first statement and 90% with the second.

> This is one of those things that could have been fixed in IEEE 1003.1

Well it was for a while, but was then "unfixed".  Unfortunately, it is
not possible with all hardware to tell precisely how much has been
written, especially in situations where there is buffering on the
interface and/or the device.  Thus the standard couldn't reasonably
require a correct count to be returned.  While many of us wanted to
require "the best data possible," there didn't seem to be a good way
to say that.  Thus the folks who wanted to keep returning no useful
data got their wish.  If anyone can come up with a better solution,
I'm willing to help push for it (of course I can't guarantee success).

Back to the original question, the best you can do is do all one-byte
writes (at the write(2) level).  That way you can be relatively (but
not absolutely) sure that no bytes have been transferred on an EINTR.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml