Re: partial failures in write(2) (and read(2))

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> It is possible for write() calls to fail partway through, after
>>> already having written some data.
>> The rightest thing to do, it seems to me, would be to return the
>> error indication along with how much was successfully written (or
>> read).  But that, of course, requires a completely new API, [...]
> I think it could be done with a signal in combination with the
> existing API.

It could!  Thank you for thinking of that; I evidently wasn't thinking
creatively enough.  Yes.  A new signal, which is generated when an I/O
operation errors after partial completion (and returning the amount of
I/O done).  I'm spinning an off-the-cuff design here: maybe, if the
signal is set to SIG_DFL, the error sticks around and is returned next
call, but if the signal is SIG_IGN or caught, not (like SIGCHLD,
SIG_IGN and SIG_DFL have different semantics even though the signal is
ignored by default).

That cound be retrofit relatively easily.

Not sure I like the price of a signal delivery just to get the error
status; an alternative I/O API could also exist.  Programs for which
the additional cost is acceptable could use the signal; those whose
tradeoffs go the other way could use the API....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B