Is it OK to poll() a device file descriptor

[Elazar Leibovich]

I think I didn't explain myself correctly, so let me give a different
example.
Let's make a file descriptor that counts to 9.

I.e, we want to emulate the behavior:

    int fd = make_counter_fd();
    assert(write(fd, buf, 100) == 11);
    assert(strcmp(buf, "0123456789") == 0);

Let me describe a very simple version of the main poll loop:

    struct poll_cb {
        int fd;
        int (*read_cb)(int fd);
        int (*write_cb)(int fd);
    };
    while (poll(&pfd, nr, -1) != -1) {
        for (int i=0; i < nr; i++) {
            if (pfd[i].revent |= POLLIN)
                poll_cbs[i].read_cb(pfd[i].fd);
            if (pfd[i].revent |= POLLOUT)
                poll_cbs[i].write_cb(pfd[i].fd);
            if (pfd[i].revent |= POLLHUP)
                pfds[i].fd = -1; // don't poll again
        }
    }

Now, in order to emulate the 0-9 file descriptor, we'll associate to a
"/dev/zero" a read callback function that looks roughly like

    int written = 0;
    char buf[10];
    int zero_to_nine_cb(int fd) {
        for (int i=0; i< 10; i++) buf[i] = '0' + i;
        close(fd); // note, we never touched the fd
    }

But I have to use a file descriptor! Otherwise poll will have no reason to
call my callback.
On Jun 19, 2013 7:47 AM, "Shachar Shemesh" <shachar at shemesh.biz> wrote:

>  On 18/06/13 22:16, Elazar Leibovich wrote:
>
> I'm using it as a fake "always non-blocking" file descriptor.
>
>  My main libevent-like poll loop looks like:
>
>      poll(fds)
>     for fd in fds:
>        if fd.revents | POLLIN:
>            fd.read_callback()
>        if fd.revents | POLLOUT:
>            fd.write_callback()
>
>  Now let's say I want a fake filedescriptor that always reads 'z's (a
> sleepy fd).
>
> Why? What you just did was to turn the whole thing into a non-sleeping
> loop. If that's the case, simply call poll with a zero timeout, so it won't
> sleep, and call your callback at the end of each loop. No need to
> artificially introduce another file descriptor into the mix.
>
> Mind you, I still don't understand WHY you'd want such a thing. This code
> will, by definition, consume 100% CPU all the time.
>
> Shachar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20130619/b55f47cc/attachment-0001.html>