1

This is probably trivial question for some people, but somehow I'm not sure about it.

When waiting with poll for event from kernel, is it that the handling of new event is done in interrupt context ?

If not, does it mean we can sleep/wait (using other commands in handler) in the handler ?

int main (void)
{
    struct pollfd fds[2];
    int ret;


    fds[0].fd = FILENO;
    fds[0].events = POLLIN;


    fds[1].fd = FILENO;
    fds[1].events = POLLOUT;

    ret = poll(fds, 2, TIMEOUT * 1000);

    if (ret == -1) {
        perror ("poll");
        return 1;
    }

    if (!ret) {
        return 0;
    }

    if (fds[0].revents & POLLIN)
    {
        /********** HANDLING EVENTS HERE ***************/
        printf ("FILENO is POLLIN\n");
    }

    if (fds[1].revents & POLLOUT)
    {
        /********** HANDLING EVENTS HERE ***************/
        printf ("FILENO is POLLOUT\n");
    }

    return 0;

}

Thank you, Ran

ransh
  • 1,589
  • 4
  • 30
  • 56

1 Answers1

2

No (in general).

When you call poll(), the processor context switches to a kernel context, and other processes (and kernel threads) run. Your process will be context switched back in at some point after at least one of your FDs is ready. In general (consider for instance a pipe), interrupt context is not required for this, though note some I/O requires interrupt context to happen (not directly connected to poll()).

abligh
  • 24,573
  • 4
  • 47
  • 84
  • It's a kernel driver which trigger timer events to userspace, module which wrapps hrtimer and supports poll from userspace. – ransh Dec 18 '16 at 09:59
  • @ransh: your question (which didn't mention timers) asked *'is it that the handling of new event is done in interrupt context'*; the answer to that is still no. There may be a timer interrupt that originates the event, but the actual processing of the event and context switch is done in the kernel context. – abligh Dec 18 '16 at 11:42