[Xcb] problem with xcb_poll_for_reply (or xcb_wait_for_reply)

[Barton C Massey]

In message <20080806100224.GB9693 at abydos.adm.naquadah.org> you wrote:
> At 1218009864 time_t, Barton C Massey wrote:
> > 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.
> 
> Well, I can confirme this behaviour which is very annoying.
> 
> My current hack is to do something like:
> 
> select()
> [=E2=80=A6]
> while((ev =3D xcb_poll_for_event(globalconf.connection)))
>   xev_restart:
>     xcb_handle_event(globalconf.evenths, ev);
> 
> /* do some other stuff */
> 
>  xcb_aux_sync(globalconf.connection);
>  /* synchronize can wake up X and pull new events in the queue */
>  if((ev =3D xcb_poll_for_event(globalconf.connection)))
>      goto xev_restart;
> 
> But I think in theory select() can miss events since there's a race.
> In practise it works quite well.

Is there something wrong about the following?

   while((ev = xcb_poll_for_event(globalconf.connection)))
       xcb_handle_event(globalconf.evenths, ev);
   select(...);
   while((ev = xcb_poll_for_event(globalconf.connection)))
       xcb_handle_event(globalconf.evenths, ev);

It shouldn't miss any events, as far as I know?  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...


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

    Bart