[Xcb] problem with xcb_poll_for_reply (or xcb_wait_for_reply)

[Barton C Massey]

I haven't dug around inside this code for a while, but I
it's hard to use select() followed by poll_for_reply() in
general.  Whenever XCB gets a chance, it likes to pull
replies off the wire in big chunks and stick them in its
internal queues.  What you can maybe do is

  select()
  poll_for_event() ...
  poll_for_reply1()
  poll_for_reply2()
  ...
  (until you don't get an outstanding reply).

In other words, any time the file descriptor gets bumped,
poll for everything that could possibly be on the wire.

Hope this helps

	Bart

In message <Pine.LNX.4.64.0808051823330.4411 at grozny.maths.univ-evry.fr> you wrote:
> 
> Hey,
> 
> I'm trying to implement xcb replies in ecore in a more fashion way, using 
> xcb_poll_for_reply or xcb_wait_for_reply. But I have some problems.
> 
> First, let me explain how I manage events. It's almost the same:
> 
> The ecore main loop is using select to examine the file descriptor 
> associated to an X connection. Ecore allows to check the file descriptor: 
> if it receive data to the filedescriptor, a callback is called.
> 
> For the events, it's easy and it is working: when an X event is sent, the 
> callback is called and we manage the event corresponding to what we have. 
> The code for that callback is roughly:
> 
> /* c is the xcb_connection_t */
> 
> while ((ev = xcb_poll_for_event(c))) {
>     uint8_t response_type = ev->response_type & ~0x80;
> 
>     if (response_type < _ecore_xcb_event_handlers_num)
>       {
>          /* we manage the event */
>  	if (_ecore_xcb_event_handlers[response_type])
>  	  _ecore_xcb_event_handlers[response_type] (ev);
>       }
> }
> 
> I want to do something similar to that but for the replies. I tried 
> several things.
> 
> 1) First, I tried to add another callback to check the file descriptor. I 
> used the poll version, with a test program (it was using 
> xcb_get_geometry_unchecked() ). All the cookies are stored into a list. I 
> read them with _ecore_xcb_cookie_next(). The callback was indeed called 
> (that is, something arrived to the file descriptor. I manage that with the 
> following code in the callback:
> 
> 
> while ((cookie = _ecore_xcb_cookie_next()))
>    {
>      if (xcb_poll_for_reply(c, cookie, &reply, NULL))
>        handle_reply(reply);
>    }
> 
> handle_reply() just prints the geometry of the window.
> 
> But xcb_poll_for_reply() returns always 0, so handle_reply() is never 
> called
> 
> 
> 2) I replaced xcb_poll_for_reply() by xcb_wait_for_reply(). It works, but 
> *only* the first time. More precisely, each time I click on the window, I 
> call xcb_get_geometry_unchecked(). For the first click, I print correctly 
> the geometry. But when I click the second time, xcb_wait_for_reply() hangs 
> and the program is not responding anymore. I think that this behavior is 
> normal, as xcb_wait_for_reply() blocks.
> 
> 3) I did the same tests than above, but within the callback of the event 
> (a second callback specific for replies should not be necessary as events 
> and replyes goes through the file descriptor. Same problem.
> 
> I have several questions:
> 
> a) Is my assulption that using only 1 callback is correct ?
> 
> b) I think that I must use xcb_poll_for_reply() and not 
> xcb_wait_for_reply(). Why isn't the code above working ?
> 
> thank you
> 
> Vincent
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb