[ On Friday, July 12, 2002 at 19:08:28 (-0700), Bill Studenmund wrote: ]
> Subject: Re: Why does read() block on I/O error?
>
> For this example, I believe it also requires device support. I think
> what's happeneing (from watching NetBSD, Windows, and MacOS on different
> devices) is that we're waiting for the CD-ROM itself to tell us if all is
> well. To do what you suggest we'd have to time out the CD-ROM access after
> a short while.

I was thinking more along the lines of assuming the device was busy
trying to fill a buffer and just returning EAGAIN immediately if the
buffer wasn't full, and then if an error occurs and the expected
sector/block/whatever can't be read from the physical media, etc. then
another error code (EIO no doubt) would be returned.  Probably the
caller would want to use select to know when the buffer (or subsequent
error) was ready.

Which of course wouldn't help for this example.   :-)

I'm assuming that the problem in this example is exclusive to, and
isolated to, the CD-ROM device and that some other critical system
resource isn't also being blocked because a bad decision has been made
to mix a "slow" device with something like a swap disk on the same
poorly designed bus (i.e. where the CD will block the swap disk while it
tries to figure out if it's going to have to return an error or not).

> Changing this will give non-intuitive behavior for everyone who is
> familiar with the current behavior. :-)

I don't exactly agree (though strictly speaking you're correct :-).

A program using O_NONBLOCK when reading a device file should be prepared
for the inevitable.  If 'vi' uses O_NONBLOCK, but doesn't do the right
thing with EAGAIN, and if users are prone to editing device files with
'vi', then perhaps it's 'vi' that needs fixing (and perhaps the user's
expectations too).  Assuming the device can sanely and safely do
read-ahead and fill a buffer before the application calls read(), then
implementing O_NONBLOCK makes perfect sense for that device (and doing
so could drastically improve the throughput of a program that does
something more than just read from the device file (eg. when it also
writes to another possibly slower and maybe un-buffered or less buffered
device such as an audio player or network port -- if it never has to
wait for a read then it can maybe keep the writes going at almost 100%).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>