--- In email@example.com
, Ankit <ankit.chaturvedi@...> wrote:
> Hi Prakash,
> Your understanding is correct. What exactly happens is that on calling
> poll_wait() the kernel calls all the fops->poll on all associated fds,
Thanks Ankit. I think you meant to say "what happens is that on callin user space::poll(fd,..)"
> passing the the global poll table. poll_wait() adds the process'
> wait_queue(events its is waiting for) to this global poll table. Or simply,
> a process adds itself to all the wait queues it is dependent on, and on
> poll/poll_wait invocation the kernel checks the global poll table if the
> event has occured. If the event is not ready (blocked on I/O, device not
> ready etc), it puts the process to sleep. Once an event has occurred (say
> read on FD), it is removed from all wait queues and all the wake handlers
> associated with the queue are called waking up the process. So from the
> outside it'll look like the poll_wait() block until an event has occured,
> but actually the event triggers the wakeup of the process.
> For more clarification on poll tabe and wait_queues, you can see do_poll()
> in fs/select.c, default_wake() & try_to_wake_up()in kernel/sched.c which
> wakes up a process. That should make things more clear.
In an exp tried out earlier in the day, poll_wait yielded inconsistent results. I overcame it by replacing poll_wait() with wait_event() and it worked exactly as I wanted.
Based on your explanation and some of the references above, I hope to emulate the good results with poll_wait.
> Ankit Chaturvedi
> GPG: 05DE FDC5 468B 7D9F 9F45 72F1 F7B9 9E16 ECA2 CC23