[Xcb] [PATCH 0/3] RFC: Fixes to Xlib problems.

[jamey at minilop.net]

Hi, Rami!

Unfortunately I have some issues with these patches.

I can't accept xcb_peek_for_event because it is inherently not
thread-safe. I didn't look too closely, but I assume that means the
libX11 patch needs to be re-thought, right?

Regarding "Prevent event waiters from blocking reply waiters": This
patch shouldn't be necessary. Do you have a pure-XCB test case that
demonstrates a bug this patch fixes?

Take a look at xcb_in.c:read_packet, which calls pthread_cond_signal
on either the reader that was waiting for this reply, or on the event
queue condition variable if it was an event. That should be sufficient
to ensure that threads wake up when there's data for them to read.

The Xlib threading bug here is that XCB doesn't provide any obvious
way for Xlib to get the next event-or-reply-or-error in
sequence-number order and block until one arrives. I've been trying to
figure out if Xlib can use select/poll to do the blocking instead of
letting XCB block, but the possibility that more than one thread might
poll the same socket makes that tricky to reason about.

On Thu, Oct 7, 2010 at 8:43 AM, Rami Ylimäki <rami.ylimaki at vincit.fi> wrote:
> Jamey, we are certainly interested in making the next generation core
> XCB available sooner than later. However, in the meanwhile ...

Sure. :-) I'd been needing to write down those ideas anyway.

Jamey