| |||||||||||||
Quotes of the weekQuotes of the weekPosted May 28, 2009 8:11 UTC (Thu) by elanthis (guest, #6227)Parent article: Quotes of the week
The POSIX I/O isn't really meant to be a general user-friendly API. That's what the C stdio facilities are for. POSIX I/O is intentionally a low-level affair used to implement higher-level facilities, and exists largely because sometimes you need very explicit control.
If write() were to always block instead of doing partial writes, for example, then multiplexed applications would become very unstable. A single bad connection or bad drive could cause the whole thing to lock when it otherwise could continue running just fine.
A great deal of coders seem to think that the answer there is to use threads or asynchronous I/O to work around blocking I/O. Those coders are, if I may say so, dumb. Single-threaded multiplexed I/O is relatively easy and painless thanks to very behavior of write() that Andi is upset with, and more general purpose blocking I/O is relatively easy thanks to the C stdio facilities and other toolkits.
(Log in to post comments)
Quotes of the week Posted May 28, 2009 16:11 UTC (Thu) by iabervon (subscriber, #722) [Link]
You can't depend on short writes alone to keep your multiplexed server from stalling, because write() can only report a short write of at least one byte (and select is not perfectly reliable); you need to use O_NONBLOCK to make conditions that are expected to clear with time errors.
The more general thing is that an error may occur, and it may be permanent or may be transient, and it may not be possible for the kernel to know which. If it occurs for the first byte, the kernel can just report it and nothing else, but if the kernel sends some of the data and then gets an error, it has to be able to report that some of the data was transferred successfully and some of it was not, in order that userspace be able to try to resolve the problem and then send the data that wasn't transferred. Once there's the possibility of userspace needing to do something other than wait in order to resolve the error, neither blocking nor failing completely is sufficient.
Quotes of the week Posted May 28, 2009 18:04 UTC (Thu) by ajross (subscriber, #4563) [Link]
That would all be true, except for the fact that stdio is itself specified as allowing short count in arbitrary conditions. The behavior of ISO C's fread/fwrite in this situation is no better, according to the standard, than that of POSIX's read/write.
Obviously sane C libraries don't return short counts from disk files in practice. But they could (and I'm sure someone will pipe up with a real world example where one does), so you still have to write the loops as a matter of standards compliance.
|
|||||||||||||