From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, sct@redhat.com
Subject: Re: [patch rfc] towards supporting O_NONBLOCK on regular files
Date: Wed, 6 Oct 2004 09:01:58 -0300 [thread overview]
Message-ID: <20041006120158.GA8024@logos.cnet> (raw)
In-Reply-To: <16739.61314.102521.128577@segfault.boston.redhat.com>
On Wed, Oct 06, 2004 at 09:13:38AM -0400, Jeff Moyer wrote:
> ==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; Marcelo Tosatti <marcelo.tosatti@cyclades.com> adds:
Hi Jeff!
> Hi, Marcelo,
>
> The text below was taken from the following standard:
>
> IEEE Std 1003.1, 2004 Edition
> The Open Group Technical Standard
> Base Sepcifications, Issue 6
> Includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002
>
>
> open()
>
> O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set:
> o If O_NONBLOCK is set, an open( ) for reading-only shall return without
> delay. An open( ) for writing-only shall return an error if no process
> currently has the file open for reading.
> o If O_NONBLOCK is clear, an open( ) for reading-only shall block the
> calling thread until a thread opens the file for writing. An open( ) for
> writing-only shall block the calling thread until a thread opens the file
> for reading.
>
> When opening a block special or character special file that supports non-
> blocking opens:
> o If O_NONBLOCK is set, the open( ) function shall return without blocking
> for the device to be ready or available. Subsequent behavior of the device
> is device-specific.
> o If O_NONBLOCK is clear, the open( ) function shall block the calling
> thread until the device is ready or available before returning.
>
> Otherwise, the behavior of O_NONBLOCK is unspecified.
>
> read()
>
> When attempting to read a file (other than a pipe or FIFO) that supports
> non-blocking reads and has no data currently available:
> o If O_NONBLOCK is set, read( ) shall return -1 and set errno to [EAGAIN].
This implies read(O_NONBLOCK) should never block.
Maybe your code should pass down __GFP_FAIL in the gfp_mask
to the page_cache_alloc() to avoid blocking reclaiming pages,
and possibly pass info down to the block layer
"if this is going to block, fail".
We have a bdi_congested() check before doing the readahead (dont RA
if the queue is full). Check if that really works - I'm afraid
it can block because the check is not done at each page
submitted, but rather at each readahead operation (which
can be several pages large).
> o If O_NONBLOCK is clear, read( ) shall block the calling thread until
> some data becomes available.
> o The use of the O_NONBLOCK flag has no effect if there is some data
> available.
>
> write()
>
> When attempting to write to a file descriptor (other than a pipe or FIFO)
> that supports non- blocking writes and cannot accept the data immediately:
> o If the O_NONBLOCK flag is clear, write( ) shall block the calling
> thread until the data can be accepted.
> o If the O_NONBLOCK flag is set, write( ) shall not block the thread. If
> some data can be written without blocking the thread, write( ) shall
> write what it can and return the number of bytes written. Otherwise, it
> shall return -1 and set errno to [EAGAIN].
>
>
> Thanks!
>
> Jeff
next prev parent reply other threads:[~2004-10-06 13:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 20:57 [patch rfc] towards supporting O_NONBLOCK on regular files Jeff Moyer
2004-10-03 19:48 ` Pavel Machek
2004-10-13 14:28 ` Jeff Moyer
2004-10-14 17:39 ` Pavel Machek
2004-10-05 11:27 ` Marcelo Tosatti
2004-10-06 13:13 ` Jeff Moyer
2004-10-06 12:01 ` Marcelo Tosatti [this message]
2004-10-07 3:31 ` Stephen C. Tweedie
2004-10-07 10:12 ` Marcelo Tosatti
2004-10-07 12:30 ` Arjan van de Ven
2004-10-11 18:32 ` Stephen C. Tweedie
2004-10-11 18:58 ` Jeff Moyer
2004-10-11 21:49 ` Stephen C. Tweedie
2004-10-13 14:26 ` Jeff Moyer
2004-10-15 15:44 ` Jeff Moyer
2004-10-15 16:19 ` Stephen C. Tweedie
2004-10-17 7:59 ` Alexandre Oliva
2004-10-17 11:20 ` Ingo Molnar
2004-10-17 19:38 ` Alexandre Oliva
2004-10-18 16:51 ` Jeff Moyer
2004-10-19 6:04 ` Alexandre Oliva
2004-10-21 20:14 ` James Antill
2004-10-05 15:35 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2004-10-05 13:07 Dan Kegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041006120158.GA8024@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sct@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.