From: "David Schwartz" <davids@webmaster.com>
To: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: SELECT() returns 1 But FIONREAD says (Input/output error)
Date: Fri, 1 Jun 2007 15:03:21 -0700 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKEEEAEEAC.davids@webmaster.com> (raw)
In-Reply-To: <46607BC5.4070408@gatworks.com>
> David Schwartz wrote:
> >> The misunderstanding is from the docs.
> >> The select() does not report device errors.
> >> Select will just "more precisely, to see if a read will not block".
> > This is a much slighter misunderstanding. The result of the 'select'
> > function tells you nothing about what a particular 'read' will
> > or will not do.
> The docs 'precisely' says that it does. I'm sorry if you cannot trouble
> yourself to read the man pages to address your issues with the correct
> functionality of the select call.
No, that's not what the docs say. That's what the docs are frequently
misunderstood to say, but that is not what they actually say. When they say,
for example, "see if a read will not block", they mean a hypothetical
concurrent read that does not take place, not a future actual read.
It's bad wording, but it is not incorrect unless you choose to misunderstand
it. For example, one could write that the 'access' function tells you if an
"'open' will succeed", but that doesn't mean an 'open' after an 'access'
*must* succeed.
Like all status-reporting functions, 'select' tells you information that is
accurate at some point in-between when you called it and when it returned
that value to you. But it makes no predictions about the future, and the
documentation does not say that it does. It does imply that it does, and
that's why it's important to correct this misconception whenever it comes
up.
POSIX's documentation is a bit clearer, saying "would block" rather than
"will block". This helps to make it clear that we're talking about a
hypothetical concurrent operation, not an actual future one.
DS
next prev parent reply other threads:[~2007-06-01 22:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-31 18:17 Uncle George
2007-06-01 1:01 ` David Schwartz
2007-06-01 1:53 ` Uncle George
2007-06-01 16:43 ` David Schwartz
2007-06-01 17:07 ` Uncle George
2007-06-01 17:33 ` David Schwartz
2007-06-01 20:04 ` Uncle George
2007-06-01 22:03 ` David Schwartz [this message]
2007-06-01 12:01 ` Uncle George
[not found] <fa.qaWJQn9l1jDV+N9wFv9WqATf44U@ifi.uio.no>
[not found] ` <fa.pq45zUHWQMSHoRGL/M4uTPfFWHg@ifi.uio.no>
2007-06-01 2:48 ` Robert Hancock
2007-06-02 0:02 ` Uncle George
[not found] <8qXzx-jY-31@gated-at.bofh.it>
2007-06-01 12:19 ` Bodo Eggert
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=MDEHLPKNGKAHNMBLJOLKEEEAEEAC.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®