poll() is buggy for duplicate file descriptors inquired for different events

["Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr@ncbi.nlm.nih.gov>]

Hi,

It looks like if a file descriptor is inquired a few times in a poll() call with different events (and for one of those events the file descriptor is "ready"),
only that occurrence gets reported correctly, and all other occurrences get the returned event just "copied over" (and thus, it may be incompatible with the
query for that occurrence).

The following simple test case demonstrates this:

$ cat poll.c 
#include <poll.h>
#include <stdio.h>
#include <string.h>

int main()
{
    int n;
    struct pollfd pfd[2];
    memset(pfd, 0, sizeof(pfd));

    pfd[0].fd = 1;
    pfd[0].events = POLLOUT;
    pfd[1].fd = 1;
    pfd[1].events = POLLIN;
    
    n = poll(pfd, 2, 1000);
    printf("n = %d\n"
    "[0].fd = %d\n"
    "[0].event = %d\n"
    "[0].revent = %d\n"
    "[1].fd = %d\n"
    "[1].event = %d\n"
    "[1].revent = %d\n",
    n,
    pfd[0].fd,
    pfd[0].events,
    pfd[0].revents,
    pfd[1].fd,
    pfd[1].events,
    pfd[1].revents);

    pfd[1].revents = 0;
    n = poll(&pfd[1], 1, 1000);
    printf("n = %d\n"
    "[1].fd = %d\n"
    "[1].event = %d\n"
    "[1].revent = %d\n",
    n,
    pfd[1].fd,
    pfd[1].events,
    pfd[1].revents);

    return 0;
}

$ gcc -Wall -o poll poll.c

$ ./poll
n = 2
[0].fd = 1
[0].event = 4
[0].revent = 4
[1].fd = 1
[1].event = 1
[1].revent = 4
n = 0
[1].fd = 1
[1].event = 1
[1].revent = 0

Note that "stdout" is inquired about ready-to-write (in [0]) and ready-to-read (in [1]).
Because it is ready-to-write, poll() returns immediately, but also having the response
ready-to-write in [1], where only "read"-compatible status (POLLIN, or POLLHUP, or POLLERR,
or just 0, if nothing of sorts was available) should have been posted -- but *never* POLLOUT!

Also note that [1] should have never been flagged as "ready", either, so the return code should have been 1, not 2.

Finally note that if [0] and [1] were swapped so that [0] was inquired for POLLIN, and [1] was inquired for POLLOUT,
the result would have still been incorrect on Cygwin ([0] returning POLLOUT for POLLIN inquired).

For the second invocation, when inquired just singly, the response is correct.

Now compare it with the correct behavior of the same code, all through, on Linux:

$ ./poll
n = 1
[0].fd = 1
[0].event = 4
[0].revent = 4
[1].fd = 1
[1].event = 1
[1].revent = 0
n = 0
[1].fd = 1
[1].event = 1
[1].revent = 0

P.S. The manual page for poll(2) says:

The bits returned in revents can include any of those specified in events, or one of the values POLLERR, POLLHUP, or POLLNVAL.

So returning POLLOUT(4) for POLLIN(1) violates the rule: bit 0 is NOT set in the binary representation of 4.

Anton Lavrentiev
Contractor NIH/NLM/NCBI