Quotes of the week [LWN.net]

Interesting, how telling somebody that they need to learn C is considered an unacceptable thing to do. Hostile to newbies, or some such. Introducing more magic that has to be learnt if one wants to read the kernel source, OTOH, is just fine...

-- Al Viro

Sorry but are you really suggesting every program in the world that uses write() anywhere should put it into a loop? That seems just like really bad API design to me, requiring such contortions in a fundamental system call just to work around kernel deficiencies.

I can just imagine the programmers putting nasty comments about the Linux kernel on top of those loops and they would be fully deserved.

-- Andi Kleen discovers POSIX

Hey, don't look at me - blame Brian Kernighan or George Bush or someone.

-- Andrew Morton disclaims responsibility

to post comments

Is worse better?

Posted May 28, 2009 6:37 UTC (Thu) by ncm (guest, #165) [Link] (1 responses)

Wasn't there a series of essays on this subject just a few years back?

Is worse better?

Posted May 28, 2009 18:38 UTC (Thu) by anton (subscriber, #25547) [Link]

If you mean the behaviour of write(2), it's certainly the first example of the New Jersey approach in Richard Gabriel's The Rise of "Worse is Better" essay (and its variants). The problem it solves is called the PC loser-ing problem there.

Quotes of the week

Posted May 28, 2009 8:11 UTC (Thu) by elanthis (guest, #6227) [Link] (2 responses)

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.

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 (guest, #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.