[Xcb] problem with xcb_poll_for_reply (or xcb_wait_for_reply)

[Barton C Massey]

In message <20080806192055.GC24837 at abydos.adm.naquadah.org> you wrote:
> At 1218049705 time_t, Barton C Massey wrote:
> > Is there something wrong about the following?
> >=20
> >    while((ev =3D xcb_poll_for_event(globalconf.connection)))
> >        xcb_handle_event(globalconf.evenths, ev);
> >    select(...);
> >    while((ev =3D xcb_poll_for_event(globalconf.connection)))
> >        xcb_handle_event(globalconf.evenths, ev);
> >=20
> > It shouldn't miss any events, as far as I know?
> 
> Well since you cannot lock the XCB event queue, I think you can still
> miss events.
> 
> First xcb_poll_for_event() can return NULL, and in the mean time you
> call select(), maybe your thread has been interrupted: meanwhile XCB has
> received a reply on the socket and puts it in your queue.
> So select() won't get it.

Sorry, I meant to add "in single threaded code" and just
plain forgot.  I agree that in multithreaded code it's a
very, very difficult dance to get right.

> > Is there
> > some reason you want to sync() here?  Or am I missing
> > something?  As long as you don't want to try to
> > asynchronously poll for replies, which is really hard with
> > XCB, I think the above should be pretty OK...
> 
> I need to sync() for an unknown reason. If I don't, some of my requests
> are not (pick one or several): sent to the X server, treated by the X
> server, visible on screen.

This sounds like a bug to me.  I assume you've reported it.
Any test case that might let us reproduce it would be really
helpful.

> > XCB is really designed for folks who want its new model for
> > asynchrony.  This model is kind of ugly against existing
> > toolkits, as it turns out.  We should try to figure out what
> > to do about that, I guess.  xcb_select(...)?  I smell Xt
> > here, and it doesn't smell pretty...
> 
> Well, in my case, the program need to do poll/select() stuff. X is not
> the only path for events, so select/poll()'ing X in the way just seems
> the obvious solution.

Yes, the xcb_select(...) solution allows you select on other
descriptors as well.  Really, though, it sounds like
spawning an extra thread or two would be way better here...
I don't know.

    Bart