Re: poll() in 2.6 and beyond

[Roland Dreier]

    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?

 - Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/