Write calls which do partial writes

[John E Van Deusen III]

In article <18735 at mips.mips.COM> (Len Lattanzi) writes:
> In article <10198 at smoke.BRL.MIL> (Doug Gwyn) writes:
>>
>> ... due to the system call being interrupted by a signal, then the
>> best thing for write() to report is the number of bytes successfully
>> transferred.

Unfortunately, if write(2) gets interrupted by a signal, the user is in
effect saying, "stop what you are doing, no matter how critical; don't
save anything; and immediately jump to a piece of code in my program".
It is difficult to see how you could re-enter the function and pick up
the pieces.  Even if a reliable number of bytes written could be
obtained from a partially completed system call, this would result in an
ambiguity.  A positive return, that is less than the number of bytes
requested, is already used to indicate that a limit was reached to the
amount of space available on the physical device or pipe.

>
> A (-1,EINTR) return from write is worthless if some bytes were
> written.  And you'll have to depend on your signal handler to not
> smash errno.  Do any of these OS/C library standards define useful
> schemes for handling system call error returns in a multi-threaded
> process besides every signal handler doing a save and restore of
> errno?

It isn't that errno has been smashed.  EINTR simply reflects the fact
that the program bombed out of write(2); so as things stand, the system
call in in error.  You are correct that this information is not very
useful if your intention is to continue the program.

As of System V release 3 the sighold and sigrelse functions were added
in order to establish critical regions of code.  In this way you can be
sure that your system calls won't be interrupted.
--
John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii