[Xcb] knowing when the X server will send the reply

[Jamey Sharp]

On Mon, Jan 28, 2008 at 11:09:53PM +0100, Vincent Torri wrote:
> On Mon, 28 Jan 2008, Jamey Sharp wrote:
>> As Bart pointed out earlier, if you do this without an extra thread, you
>> need to be very careful not to spin. xcb_poll_for_reply, like
>> xcb_poll_for_event, will not block when there is no input. If you don't
>> have any other work to do, you need some other way to block so you don't
>> waste all your CPU time. If you're very careful, you can do that with
>> select(2) or poll(2) on the file descriptor of the socket connected to
>> the X server, but there are subtle traps there too.
>
> raster already does that stuff for X events and xcb_poll_for_event (well, i 
> wrote that xcb part, actually). We indeed do a select on the fd.

Huh, sure enough. That code looks about right. I think you'll want to
make the "buf_func" always return 1, though. XCB has no direct
equivalent to the XPending call that ecore_x uses there, but
xcb_poll_for_(event|reply) is just as efficient as XPending, so you
should just run the full scan for pending items. I think the same
argument pretty clearly applies to ecore_x on Xlib, for that matter...

On Mon, Jan 28, 2008 at 02:37:44PM -0800, Barton C Massey wrote:
> These races with the external world / OS may occur even in
> single-threaded programs.  I can't come up with an easy
> example offhand, and there may not be any.

The issue to worry about here is not a "race" in the classical sense,
but it has about the same result. When you send a request, XCB (like
Xlib) may read some unrelated response off the wire. Then when you get
around to your select() call, there's nothing on the wire to read, so
you block--but you could have made progress by polling XCB's queues. In
the worst case, this leads to your application hanging, so it can also
resemble a deadlock.

> I'm just saying you'll have to think about it carefully,
> because this sort of usage of XCB was not well thought out
> or tested.

No kidding. Official position: we don't encourage this, but have fun.
kthxbye. :-)

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20080129/6ef27b74/attachment.pgp