Write calls which do partial writes

[Frank Mayhar]

In article <530 at visdc.UUCP> jiii at visdc.UUCP (John E Van Deusen III) writes:
>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.

Pardon my saying so, but, CRAP!  I've fought with this piece of Unix wrong-
headedness, and I see no good reason for it.  At the very least, errno should
contain some indication that the operation was interrupted, and the return
should be the number of bytes written.  Or that information should be 
retrievable in some fashion (a new system call, perhaps?).  There are many
good reasons to interrupt a process asynchronously (timer runout, I/O 
completion, etc.), and doing so should _always_ be recoverable.  My personal
opinion is that write()s should be atomic, and uninterruptible.  read()s
may or may not be atomic (I think they should be), but if they are not, it
should be possible to easily recover in this case, as well.
 
>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.

About d*mn time!

Note that I'm not flaming you, I'm flaming what I see as a Unix misfeature.
-- 
Frank Mayhar  ..!uunet!ladcgw!frank (soon to be frank at ladc.bull.com)
              Frank-Mayhar%ladc at bco-multics.hbi.honeywell.com (until June 1)
              Bull HN Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045  Phone:  (213) 216-6241