[Xcb] [PATCH] Handle EAGAIN errno from poll(2) or select(2)

[Jeremy Huddleston Sequoia]

> On Aug 20, 2015, at 09:21, Josh Triplett <josh at joshtriplett.org> wrote:
> 
> On Thu, Aug 20, 2015 at 12:18:41AM -0700, Jeremy Sequoia wrote:
>> Yeah, I thought about sleeping before retrying in the EAGAIN case to
>> avoid a possible busy loop.  I can do that if you prefer.
>> 
>> As I indicated in the commit message, there is know known fallout from
>> the lack of EAGAIN handling.  There is no behavioral problem.  Indeed
>> the only time someone should ever get back EAGAIN from poll or select
>> on darwin is under resource pressure, and its likely the user would
>> have bigger concerns than this at that point.
>> 
>> I just happened to notice this while tracing code to figure out why
>> someone on stackoverflow was seeing recv() of the DISPLAY socket
>> erring out with EAGAIN and then hanging.
> 
> If Darwin/OSX returns EAGAIN to a blocking call under *any*
> circumstances, including "resource pressure", that's a serious bug.
> Don't work around it in XCB or any other library, *especially* because
> no other platform should behave the same way.  EAGAIN means "The socket
> is marked nonblocking and the receive operation would block, or a
> receive timeout had been set and the timeout expired before data was
> received."  

No, that is not what EAGAIN means.  From SUSv4 at http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html

"""
The poll() function shall fail if:

[EAGAIN]
The allocation of internal data structures failed but a subsequent request may succeed.
...
"""

True, select(2) does not specify EAGAIN as a possible returned error in SUSv4 (http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html), but darwin extends the standard to indicate that select(2) can return EAGAIN for basically the same reasons as poll(2) can.

> A blocking call with no timeout should never return EAGAIN;
> it should either block or return some fatal error.

Not according to UNIX.

> Libraries should *definitely* not have to include "wait a bit and try
> again" logic; that's the kernel's job.

Hence why I decided to just try again immediately.

> If you want a way to work around that on Darwin

This is a UNIX issue (for poll(2)).  Yes, select(2) returning an EAGAIN error is a darwin *extension*, but I don't imagine that should cause any additional headaches given that we already have to handle that exact case for the poll(2) codepath.

> , you could create some
> wrapper library around functions like recv that hides the incorrect
> behavior.  But first, I'd suggest reporting a bug against Darwin for
> violating the spec.

That's not necessary, as I've indicated above.

--Jeremy