Re: poll() in 2.6 and beyond

["Richard B. Johnson" <root@chaos.analogic.com>]

On Tue, 2 Mar 2004, Roland Dreier wrote:

>     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?
>

You are playing games with semantics because you are wrong.
The code in fs/select.c about line 101, adds the current caller
to the wait-queue. This wait-queue is the mechanism by which the
current caller sleeps, i.e., gives the CPU up to somebody else.
That caller's thread will not return past that line until
a wake_up_interruptible() call has been made for/from the
driver or interface handling that file descriptor. In this manner
any number of file discriptors may be handled because the poll()
routine for each of then makes its own entry into the wait-queue
using the described mechanism.

> 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?
>

Explained above.
[SNIPPED bullshit]


Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.