On Tue, 9 Jul 2002, Greg A. Woods@planix.com Greg A. Woods; Planix, Inc. wrote:

> [ On Tuesday, July 9, 2002 at 09:16:39 (+0200), Jaromir Dolecek wrote: ]
> > Subject: Re: Why does read() block on I/O error?
> >
> > O_NONBLOCK has only effect on IPC descriptors, like sockets and
> > pipes. It doesn't have any effects for file descriptors.
>
> It also works for file descriptors open on "slow" devices, which
> presumably a CD-ROM could be considered to be, at least when accessed in
> any sequential style....
>
>      If the O_NONBLOCK flag is specified, do not wait for the device or file
>      to be ready or available.  If the open() call would result in the process
>      being blocked for some reason (e.g., waiting for carrier on a dialup
>      line, or the file is currently locked), open() returns immediately with
>      an error code of -1, setting errno to EAGAIN.  This flag also has the ef-
>      fect of making all subsequent I/O on the open file non-blocking.
>
> I believe it requires device driver support though, and I don't imagine
> the various CD-ROM devices have such support.

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.

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

Also note that if you do this, weird things will happen with vi on cdrom
file systems. As I recall from when we were working on dmfs (a teriary
storage system), vi sets O_NONBLOCK, but doesn't deal with it doing
anything. When we had files respecting O_NONBLOCK for reading files from
tape, vi ended up getting a corrupted view of the file.

So as long as you're playing with a file, don't rely on O_NONBLOCK.

Take care,

Bill