Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: help needed on a unix system-call question
Keywords: signal, system-call, read, unix v
Message-ID: <1485@mcgill-vision.UUCP>
Date: 29 Mar 89 11:57:12 GMT
References: <2100@iitmax.IIT.EDU> <1134@auspex.UUCP> <7553@june.cs.washington.edu>
Organization: McGill University, Montreal
Lines: 28

In article <7553@june.cs.washington.edu>, ka@june.cs.washington.edu (Kenneth Almquist) writes:
> guy@auspex.UUCP (Guy Harris) writes:
>> Assuming by "is it possible to lose the partially read data" you
>> mean "if the 'read' blocks, and then transfers some data and blocks
>> waiting for more data, and *then* gets interrupted by a signal, is
>> the data it transferred more-or-less lost", the answer is "yes, and
>> [...]" [...].
> Reads on cooked tty devices block until an entire line is available
> and then copy in the entire line at once.

The original posting seems to have expired here.  There is one common
case which *looks* like "partially read" data being "lost", even though
this is not really true: when the signal coming in is due to a special
character (interrupt or quit, for example) being typed on the tty
that's being read from.  In this case, the input buffer is generally
flushed, losing any partial line that's been typed.  Until you realize
that the partial line is being buffered in the kernel and not
transferred to the user's buffer until you push return (and therefore
isn't partially read at all), this looks a lot like "losing partially
read data".

The original question probably belonged in comp.unix.questions, but we
all know nobody pays any attention to the distinction any longer :-(.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu