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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox