Subject: Re: Why does read() block on I/O error?
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/12/2002 19:08:28
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.