Loading ...
Sorry, an error occurred while loading the content.

Re: [blug-prog] Kernel programming : poll_wait, polling on a file descriptor

Expand Messages
  • Ankit
    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,
    Message 1 of 3 , Mar 6 2:22 AM
    • 0 Attachment
      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,
      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.


      --
      Ankit Chaturvedi
      GPG: 05DE FDC5 468B 7D9F 9F45 72F1 F7B9 9E16 ECA2 CC23
      <http://dumpyard.tumblr.com>


      On Thu, Mar 5, 2009 at 3:38 PM, Prakash K.B. <prakash_kb@...> wrote:

      > Hello,
      >
      > Would someone kindly explain the effect of invoking poll_wait() kernel
      > routine?
      >
      > My limited/half baked understanding is that when an user space application
      > invokes polls on a file descriptor, it leads to the kernel invoking the poll
      > handler registered with file_operations for the desired device.
      >
      > It is now the responsibility of the poll handler to either return a mask to
      > the user space application indicating what operations (such as Read,
      > write)are likely to succeed or even place the calling process in sleep
      > state.
      >
      > An example straight from Mssrs Rubini and Corbet text book is as follows:
      >
      > unsigned int xxx_poll(struct file *filp, poll_table *wait)
      > {
      > if (write_data_available)mask = Write flags;
      > if (read_data_available)mask = Read flags;
      >
      > poll_wait(filp, &ReadWaitQueue, wait);
      > poll_wait(filp, &WriteWaitQueue, wait);
      >
      > return mask;
      > }
      >
      > What is poll_wait trying to accomplish? Or rather, how is the calling
      > process placed in sleep state?
      >
      > Best regards,
      > Prakash
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Prakash K.B.
      ... Thanks Ankit. I think you meant to say what happens is that on callin user space::poll(fd,..) ... In an exp tried out earlier in the day, poll_wait
      Message 2 of 3 , Mar 6 4:44 AM
      • 0 Attachment
        --- In linux-bangalore-programming@yahoogroups.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
        > <http://dumpyard.tumblr.com>
        >

        Best regards,
        Prakash
      Your message has been successfully submitted and would be delivered to recipients shortly.