From: Bill Davidsen <davidsen@tmr.com>
To: Roland Dreier <roland@topspin.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: poll() in 2.6 and beyond
Date: Tue, 02 Mar 2004 17:53:33 -0500 [thread overview]
Message-ID: <4045106D.8060902@tmr.com> (raw)
In-Reply-To: <1vpWa-7Py-19@gated-at.bofh.it>
Roland Dreier wrote:
> I don't know why I continue this, but.... can you point out the line
> in the kernel 2.4 source for __pollwait() where it sleeps?
>
> Or think about it. Suppose a user called poll() with two fds, each of
> which belonged to a different driver. Suppose each driver slept in
> its poll method. If the first driver never became ready (and stayed
> asleep), how would poll() return to user space if the second driver
> became ready?
>
> What actually happens is that each driver registers with the kernel
> the wait queues that it will wake up when it becomes ready. But the
> core kernel is responsible for sleeping, outside of the driver code.
Could you maybe go back to the initial report, which is that after
poll() gets wrong status? It's nice to argue about where the process
waits, but the issue is if it gets the same status with 2.4 and 2.6, and
if not which one should be fixed.
Richard: can you show this with a small demo program? I assume you
didn't find this just by reading code ;-)
next parent reply other threads:[~2004-03-02 22:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1vmPm-4lU-11@gated-at.bofh.it>
[not found] ` <1vonq-6dr-37@gated-at.bofh.it>
[not found] ` <1voGY-6vC-41@gated-at.bofh.it>
[not found] ` <1vpjt-7dl-17@gated-at.bofh.it>
[not found] ` <1vpCV-7wY-41@gated-at.bofh.it>
[not found] ` <1vpWa-7Py-19@gated-at.bofh.it>
2004-03-02 22:53 ` Bill Davidsen [this message]
2004-03-02 22:57 ` poll() in 2.6 and beyond Roland Dreier
2004-03-02 23:32 ` Richard B. Johnson
2004-03-03 0:07 ` John Muir
2004-03-03 1:18 ` Richard B. Johnson
2004-03-03 4:04 ` Roland Dreier
2004-03-03 12:38 ` Richard B. Johnson
2004-03-03 14:29 ` Davide Libenzi
2004-03-03 3:57 ` David Dillow
2004-03-03 18:23 ` Richard B. Johnson
2004-03-03 19:29 ` Dave Dillow
2004-03-03 20:10 ` Richard B. Johnson
2004-03-03 22:25 ` Linus Torvalds
2004-03-03 22:42 ` Richard B. Johnson
2004-03-03 23:14 ` Linus Torvalds
2004-03-03 22:52 ` Linus Torvalds
2004-03-03 23:07 ` Richard B. Johnson
2004-03-03 3:06 linux
-- strict thread matches above, loose matches on Subject: below --
2004-03-02 18:21 Richard B. Johnson
2004-03-02 20:04 ` Roland Dreier
2004-03-02 20:24 ` Richard B. Johnson
2004-03-02 21:00 ` Roland Dreier
2004-03-02 21:26 ` Richard B. Johnson
2004-03-02 21:39 ` Roland Dreier
2004-03-02 21:59 ` Richard B. Johnson
2004-03-02 22:41 ` Dave Dillow
2004-03-02 22:56 ` Roland Dreier
2004-03-02 23:16 ` Richard B. Johnson
2004-03-02 23:21 ` Roland Dreier
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=4045106D.8060902@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@topspin.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