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

[Jamey Sharp]

On Sat, Jan 26, 2008 at 02:53:19PM -0800, Barton C Massey wrote:
> Vincent Torri wrote:
> > raster wants an event driven design for xcb support in ecore. That
> > means that he wants to send an ecore event when a requested reply is
> > available. In the main loop, we get teh ecore event and the
> > associated xcb reply
> 
> I don't know of any reason that xcb_poll_for_reply() wouldn't work.

I'll assert something stronger: This is the case that xcb_poll_for_reply
was added for. :-) On the other hand,

> The approach I would take is to give up and be multithreaded.

I agree completely.

There are examples of both styles of reply callbacks in util/reply/:
- a single thread occasionally polling for replies, or
- making a separate thread to block on each reply.
They aren't well tested and probably have bugs, but should give you the
general idea.

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.

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/20080128/0a290e2b/attachment.pgp