Re: poll() in 2.6 and beyond

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

On Tue, 2 Mar 2004, Roland Dreier wrote:

>     Richard> You are playing games with semantics because you are
>     Richard> wrong.  The code in fs/select.c about line 101, adds the
>     Richard> current caller to the wait-queue.
>
> I assume you mean the call to add_wait_queue() there.  That does not
> sleep.  Look at the implementation.  add_wait_queue() is defined in
> kernel/fork.c -- it just does some locking and calls
> __add_wait_queue().  __add_wait_queue() is really nothing more than
> a list_add().  There's nothing more to it and nothing that goes to
> sleep.  Where do you think add_wait_queue() goes to sleep?
>
>     Richard> This wait-queue is the mechanism by which the current
>     Richard> caller sleeps, i.e., gives the CPU up to somebody else.
>     Richard> That caller's thread will not return past that line until
>     Richard> a wake_up_interruptible() call has been made for/from the
>     Richard> driver or interface handling that file descriptor. In
>     Richard> this manner any number of file discriptors may be handled
>     Richard> because the poll() routine for each of then makes its own
>     Richard> entry into the wait-queue using the described mechanism.
>
> But there's only one thread around: the user space process that called
> into the kernel via poll().  If the first driver goes to sleep, which
> thread do you think is going to wake up and call into the second
> driver?
>

There are two routines where the CPU is actually given up,
do_select() and do_poll().  Search for schedule_timeout().
Once the scheduler has the CPU, it's available for any of
the other drivers. It's also available for the timer queues,
other tasks, and the interrupts.

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