[Xcb] problem with xcb_poll_for_reply (or xcb_wait_for_reply)

[Jamey Sharp]

I think the follow-ups on this thread went off in the wrong direction
for Vincent's problem. I could be wrong...

On Tue, Aug 05, 2008 at 06:56:34PM +0200, Vincent Torri wrote:
> 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:

This looks sensible, assuming that the real code frees the events.

> while ((cookie = _ecore_xcb_cookie_next()))
>    {
>      if (xcb_poll_for_reply(c, cookie, &reply, NULL))
>        handle_reply(reply);
>    }

As soon as xcb_poll_for_reply returns 0, you know none of the later
replies can have arrived yet, so you should stop processing the queue
and go back to select(). In fact, you should only delete a cookie from
the queue when xcb_poll_for_reply returns non-zero for that cookie; if
you got 0, you need to check it again later.

To be completely general, you should only delete a cookie when
xcb_poll_for_reply returns non-zero *and* reply is null. That means XCB
has proven that no more replies can come for that cookie in the future.
Xlib does this. However, if you know that all your requests will have at
most one reply, you don't need to go that far.

> 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 

One difference is that xcb_wait_for_reply will flush the output queue if
necessary, and xcb_poll_for_reply won't. (But if you haven't flushed
before calling select(), you won't wake up again until an event occurs
anyway.)

Make sure that you call xcb_flush() before calling select(), ideally
using an idle-callback if ecore supports those.

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

Yeah, that's weird. Since I don't really know what's going on, I'm going
to make some wild guesses.

- Are you sure that your cookie queue is working correctly, returning
  the same values you put into it?

- Is the connection getting shut down into an error state? If the
  cookies are coming back containing 0, something's wrong.

You might run your test program under gdb, and when it hangs, hit ctrl-c
and look at the backtrace. That may provide some clues.

> 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.
> 
> a) Is my assulption that using only 1 callback is correct ?

Yes. I wouldn't be shocked if it fails if you use two callbacks.

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