[Xcb] [Bug 45776] all X programs hanging in libxcb on GNU/kFreeBSD

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45776

--- Comment #6 from Josh Triplett <josh at freedesktop.org> 2012-02-08 12:37:30 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > I looked up the description of MSG_WAITALL in the recv manpage:
> [...]
> > This seems entirely wrong for these calls to recv.  Passing MSG_WAITALL
> > suggests that we don't want the OS to return until it has filled the entire
> > input buffer, whereas we clearly want the OS to return as soon as it has an X
> > response for us. 
> 
> That's only true for _xcb_in_read() (which I totally missed, whoops).
> read_block() would loop until it has read as much data as was asked for anyway.

Fair enough.  Does dropping MSG_WAITALL from _xcb_in_read solve the problem, or
do programs still hang in read_block()?

> > That would certainly explain the hangs.
> 
> Well, it doesn't hang, it busy-loops with recv() always returning EAGAIN and
> this behavior isn't explained yet.

That one seems fairly straightforward as well.  We put sockets into
non-blocking mode, so any read/recv operation that would block will instead
return EAGAIN.  MSG_WAITALL tells recv to block until it fills the buffer, so
it would make sense that if recv couldn't immediately fill the buffer it would
return EAGAIN.

It also wouldn't surprise me if Linux effectively ignores MSG_WAITALL on
non-blocking sockets (since it doesn't seem like an overly sensible
combination), which would explain why this hang didn't occur on Linux.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.