>>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
