[xcb] XCB polling and single-threadedness

[Soeren Sandmann]

Jamey Sharp <jamey@sharp.ath.cx> writes:

> > The patch below makes XCBFillBuffer empty the file descriptor instead
> > of calling read() just once.
> 
> Is there any reason to believe that this will make any difference? I
> figure that if there's more data readable after the first read, then
> XCB's buffer was filled on the first call. If that's true, the second
> read will be an expensive no-op under any circumstances.

I don't know if it will make any real difference, but in some
unrelated networking code I have someting like this:

    #define BUF_SIZE 8192

    while (TRUE)
    {
        unsigned char msg [BUF_SIZE];
        ssize_t len;
        
        len = recv (connection->fd, msg, BUF_SIZE)
        if (len < 0)
        {
            if (errno != EAGAIN)
                 /* handle error */
            break;
        }
        
        if (len == 0)
        {
            /* handle close */
            break;
        }
        
        /* queue read handler */
    }

and while most second recv()s are noops, it is not that uncommon for
strace to report things like:

[...]
20:57:10.178201 poll([{fd=5, events=POLLIN, revents=POLLIN}], 1, 49) = 1
20:57:10.190586 recv(5, "HTTP/1.1 200 OK\r\nDate: Sun, 07 J"..., 8192, 0) = 1368
20:57:10.190742 recv(5, "Accept-Ranges: bytes\r\nContent-Le"..., 8192, 0) = 1368
20:57:10.190846 recv(5, "\234\204J\234\214s\245s\0\245s\10\245\224{\245\245\245"..., 8192, 0) = 1368
20:57:10.190988 recv(5, "\315\227\"\244\256w\r\200\347\235\216,\245\200\236\0>\24"..., 8192, 0) = 1106
20:57:10.191072 recv(5, 0xbfffc2b8, 8192, 0) = -1 EAGAIN (Resource temporarily unavailable)
20:57:10.192198 poll([{fd=5, events=POLLIN, revents=POLLIN}], 1, 35) = 1
[...]

ie, four recv()s in a row, all of which are much smaller than
BUF_SIZE.