[Xcb] Feature Request: Function "xcb_test_for_event"

[Bart Massey]

On Tue, Apr 9, 2013 at 2:00 PM, Josh Triplett <josh at joshtriplett.org> wrote:
>
> Bart Massey <bart at cs.pdx.edu> wrote:
>
> >By now, I'm completely lost.
> >
> >xcb_block_until_event() is called xcb_wait_for_event() as far as I
> >know.
> >The non-blocking version is xcb_poll_for_event(), but it's almost
> >always a
> >bad idea to call it.
>
> xcb_wait_for_event returns the event. This new function wouldn't.


I get that. It just seems kind of gratuitous. I'm not sure why I'd
ever want to block waiting for an event I didn't need right now,  but
if I did it would be so easy to just stash the event somewhere until
it was needed.

>
> >As Josh suggests, if you want to wait on multiple things at once, spawn
> >a
> >blocking thread per thing, and demux the result using the usual thread
> >mechanisms. Pipes are probably overkill here: just use a locked queue.
> >If
> >you use a semaphore for locking the queue, you can block until
> >something is
> >in it conveniently.
>
> Pipes help if you have a pile of other fds to wait on.


Still not getting this. It seems to me that once you admit that your
program is multi-threaded, it's arguably better to avoid select() and
friends altogether and just use a thread per fd with blocking reads
and a queue. A little heavier weight, but way easier to get right and
test and debug.

--Bart