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

[Vincent Torri]

On Mon, 28 Jan 2008, Jamey Sharp wrote:

> 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.


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. If you 
want to look ath the code :

http://web.enlightenment.org/viewvc/e17/libs/ecore/src/lib/ecore_x/ecore_x.c?annotate=1.130

(lines 389, 646 and 671)

and

http://web.enlightenment.org/viewvc/e17/libs/ecore/src/lib/ecore/ecore_main.c?annotate=1.33

(lines 107 and 284)

thanks for the reply

Vincent