lkml.org 
[lkml]   [2004]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: poll() in 2.6 and beyond
Richard B. Johnson wrote:

> > 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 ;-)
>
> Yes. The code I attached earlier shows that the poll() in a driver
> gets called (correctly), then it calls poll_wait(). Unfortunately
> the call to poll_wait() returns immediately so that the return
> value from the driver's poll() is whatever it was before some
> event occurred that the driver was going to signal with
> wake_up_interruptible().
>
The documentation referred to earlier
(http://www.xml.com/ldd/chapter/book/ch05.html#t3) clearly states that
the poll function implementation for a device should:
"1. Call /poll_wait/ on one or more wait queues that could indicate a
change in the poll status.
2. Return a bit mask describing operations that could be immediately
performed without blocking."
What happens is if your device has data ready RIGHT NOW (without any
waiting), the information regarding that is returned.

Now, if you look closely at the implementation of do_poll(), it will
loop forever until any device returns that data is available (or the
timeout occurs). After data is available, do_pollfd() function no longer
adds the devices to the wait queue.

What this means is that the first time through each device is added to
the wait queue. After the process is woken up from schedule_timeout (or
the timeout occurs), then it will loop through each device again to
either add that device to the wait queue again, or determine that there
is data ready to be read/written, or an error or whatever. do_pollfd()
then increases count, and do_poll() exits from it's loop (and wait
queues are cleaned-up in sys_poll()).

So, yes, the poll_wait() returns immediately, it should not wait, and
your poll method should return the device's CURRENT status in the poll
mask. Don't worry, because when your device wakes the waiting process
when data is ready, the device's poll function is called again and you
again can return the CURRENT status.

Please let me know if I'm misunderstanding this, but quite frankly,
poll_wait CANNOT wait, for the very reasons described in previous posts:
when multiple devices are polled, then poll_wait is called FOR EACH DEVICE.

Cheers,

..John


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

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.293 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site