O_NONBLOCK, read(), select(), NFS, Ext2, etc.

O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Michael Rothwell]

The man pages for open, read and write say that if a file is opened
using the O_NONBLOCK flag, then read() and write() will always return
immediately and not block the calling process. This does not appear to
be true; but perhaps I am doing something wrong. If I open() a file (on
2.2.18) from a floppy or NFS mount (to test in a slow environment) with
O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on
the file descriptor, select() always returns 0.

Is there a way to make open(), read() and write() live up to their
manpages?

-M

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Chris Wedgwood]

On Thu, Jan 11, 2001 at 09:34:08PM -0500, Michael Rothwell wrote:

    The man pages for open, read and write say that if a file is opened
    using the O_NONBLOCK flag, then read() and write() will always return
    immediately and not block the calling process. 

the man pages are wrong


  --cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Alan Cox]

> using the O_NONBLOCK flag, then read() and write() will always return
> immediately and not block the calling process. This does not appear to
> be true; but perhaps I am doing something wrong. If I open() a file (on
> 2.2.18) from a floppy or NFS mount (to test in a slow environment) with
> O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on
> the file descriptor, select() always returns 0.

The definition of immediate is not 'instant'. Otherwise no I/O system would
ever return anything but -EWOULDBLOCK. Its that it won't wait when there is
no data pending. On a floppy there is always data pending

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Michael Rothwell]

Alan Cox wrote:
> 
> > using the O_NONBLOCK flag, then read() and write() will always return
> > immediately and not block the calling process. This does not appear to
> > be true; but perhaps I am doing something wrong. If I open() a file (on
> > 2.2.18) from a floppy or NFS mount (to test in a slow environment) with
> > O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on
> > the file descriptor, select() always returns 0.
> 
> The definition of immediate is not 'instant'. Otherwise no I/O system would
> ever return anything but -EWOULDBLOCK. Its that it won't wait when there is
> no data pending. On a floppy there is always data pending


How about using fcntl(), O_ASYNC and SIGIO? Or maybe a broader question:
what's the preferred/working way to do async file i/o on Linux?

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Andries.Brouwer]

    From: Chris Wedgwood <cw@f00f.org>

    On Thu, Jan 11, 2001 at 09:34:08PM -0500, Michael Rothwell wrote:

        The man pages for open, read and write say that if a file is opened
        using the O_NONBLOCK flag, then read() and write() will always return
        immediately and not block the calling process. 

    the man pages are wrong

Don't you think cc'ing the man page maintainer [aeb@cwi.nl]
would be a good idea whenever you think something is wrong
in the man pages? You never know, they might even improve.

In this particular case I don't think anything is actually
wrong, but I can well imagine that someone can invent clearer
wording. It would also be useful to more clearly separate
POSIX-mandated behaviour and actual Linux behaviour.
Suggestions and patches are welcome as always.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Alexander V. Lukyanov]

On Fri, Jan 12, 2001 at 09:40:55AM +0000, Alan Cox wrote:
> > be true; but perhaps I am doing something wrong. If I open() a file (on
> > 2.2.18) from a floppy or NFS mount (to test in a slow environment) with
> > O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on
> > the file descriptor, select() always returns 0.
>
> The definition of immediate is not 'instant'. Otherwise no I/O system would
> ever return anything but -EWOULDBLOCK. Its that it won't wait when there is
> no data pending. On a floppy there is always data pending

I have a long standing idea on modifying poll/read/write behavior on
regular files opened in O_NONBLOCK mode. How about the following scheme:

   * poll returns POLLIN/POLLOUT on regular files only if the data are
   in buffer cache/there is room for write().
   * read returns EAGAIN if the data are not in buffer cache.
   * write returns EAGAIN if there is no room (yet) to store the data.

All the operation should signal to IO subsystem that the data are
needed in cache/the room has to be freed.

--
   Alexander.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Dan Kegel]

Michael Rothwell (rothwell@holly-springs.nc.us) wrote:

> How about using fcntl(), O_ASYNC and SIGIO? 

Don't think that's supported for disk files yet, at least by the
kernel.  glibc does aio emulation with threads, which isn't great.

> Or maybe a broader question: 
> what's the preferred/working way to do async file i/o on Linux? 

SGI has done lots of work on this, using kernel threads; 
they don't have a patch yet for 2.4.0, but they do support
2.2.17 and 2.4.0-test10.

TUX uses async I/O, I think, but it's inside the kernel.
I hear plans are afoot for giving userspace async I/O that
avoids creating threads; that should be more scalable than
SGI's approach, if it ever happens.

See http://www.kegel.com/c10k.html#aio for links and a few notes.
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/