[Xcb] Xlib/XCB in multi-threaded situation results in deadlock

[Jamey Sharp]

On Fri, Mar 18, 2011 at 8:08 AM, Rami Ylimäki <rami.ylimaki at vincit.fi> wrote:
> On 03/17/2011 11:25 PM, Jamey Sharp wrote:
>> My new thought is to introduce
>>
>> xcb_generic_event_t *xcb_wait_for_event_until(xcb_connection_t *c,
>> unsigned int request);
>> ...
>
> Makes sense to me. ...

Thanks for checking over my plan. Since you sanity-checked it, I
implemented it today, and `glthreads -n 6` works now! That was the
simplest test case I'd seen reported. And indeed, on released versions
of libX11, it instantly hangs at startup, and then proceeds one frame
at a time every time you give it a keyboard event, which is exactly
the symptom you'd expect for this bug.

Furthermore, this plan doesn't seem to have broken `ico -threads 16`
(which worked before) or the single-threaded clients I've tested so
far, and Josh has reviewed the patches. So I have some confidence in
the fix.

I've pushed the libxcb patches to git master. I can't reasonably push
the libX11 patch until there's a new release of libxcb for it to
depend on though, and I gather libxcb master currently has
regressions... :-( Evgeny's alignment plan might be release-critical
now?

> Thanks for the comments, I'll prepare new versions of those patches.

Excellent. I'd like to get your fix for excessive reads released at
the same time as the _XReadEvents fix, if possible.

>>> 2) Clean up EAGAIN errors from read when connection is polled in
>>> _XEventsQueued
>
> I never expected those patches to be accepted upstream and I'm not going to
> defend them :).

Oh, OK. :-)

Jamey