From: Roland Dreier <roland@topspin.com>
To: root@chaos.analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: poll() in 2.6 and beyond
Date: 02 Mar 2004 13:39:24 -0800 [thread overview]
Message-ID: <52n06zq67n.fsf@topspin.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0403021624300.2296@chaos>
Roland> I don't think so. Even in kernel 2.4, poll_wait() just
Roland> calls __pollwait(). I don't see anything in __pollwait()
Roland> that sleeps. Think about it. How would the kernel handle
Roland> userspace calling poll() with more than one file
Roland> descriptor if each individual driver slept?
Richard> Well what to you think they do? Spin?
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.
Really, read:
<http://www.xml.com/ldd/chapter/book/ch05.html#t3>
You might believe you're familiar with poll() but I think it would
help to read what the Linux Device Drivers book has to say. It
answers the exact question you're asking, and if you don't believe me
you might believe the definitive published book.
- Roland
next prev parent reply other threads:[~2004-03-02 21:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-02 18:21 poll() in 2.6 and beyond 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 [this message]
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
[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
2004-03-02 22:57 ` 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
-- strict thread matches above, loose matches on Subject: below --
2004-03-03 3:06 linux
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=52n06zq67n.fsf@topspin.com \
--to=roland@topspin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.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