Not a typewriter

[Robert Bradbury]

In article <573 at codas.ATT.UUCP>, mikel at codas.ATT.UUCP (Mikel Manitius) writes:
> 
> Yes, you are correct. I don't always trust the documentation, so I
> rarely read it. I checked by writing a small C program, write does
> indeed return -1 not 0, when the call is interrupted and no bytes
> were read.
> 			Mikel Manitius

The problem is much more subtle than is indicated by this discussion.
A -1 will be returned and errno set to EINTR if a signal has been
received anytime from the beginning to the end of the system call.
In cases where the the system call may be completed without doing
a sleep() [a read from a teletype where the user has typed ahead or
a write to a pipe] the system call will actually have done the work
successfully even though it returns an error.

This maybe I did it and maybe I didn't aspect of system calls in the
presence of signals has caused me to write some very strange code
from time to time.  The Berkeley folks tried to solve this in 4.1
by "restarting" the system call.  Does this work right all the time?

It would seem the real problem revolves around the need for multiple
return values from system calls and/or the ability to prevent signals
(without the overhead of more system calls) for some system calls.

Does anyone know if P1003 or System 5.3 have come up with solutions for this
problem?


-- 
Robert Bradbury
Oracle Corporation
(206) 364-1442                            {ihnp4!muuxl,hplabs}!oracle!bradbury