[Xcb] Feature Request: Function "xcb_test_for_event"

[Jamey Sharp]

On Wed, Apr 10, 2013 at 11:45:38AM -0700, Josh Triplett wrote:
> On Wed, Apr 10, 2013 at 10:39:19AM -0700, Bart Massey wrote:
> > 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.
> 
> The original request in this thread would disagree with that, and I can
> somewhat understand its use case.  Ideally I'd rather solve that problem by
> select()ing the X connection, but I don't see how to do that safely with
> the semantics of X and XCB.

Is that really so hard? Undocumented, certainly--but hard? :-)


1) xcb_poll_for_reply for the lowest sequence-number of any request you
have pending. Keep processing responses as long as it returns true
(meaning that xcb_wait_for_reply would not have blocked).

2) xcb_poll_for_queued_event and process events until it returns NULL
(meaning that there are no more events queued locally).

3) Add xcb_get_file_descriptor(c) to your poll/select FDs and block.


I haven't tested that procedure, but I believe that since Rami Ylimäki
added xcb_poll_for_queued_event two years ago, it's been possible to
safely use XCB in a single-threaded poll or select loop. The above calls
are guaranteed not to read from the socket.

I'd advocate against adding API that pushes poll/select loops inside
XCB, on the principle that if every library required that, you'd never
be able to use any of them together.

By contrast, assuming I haven't forgotten something, the above approach
should work with glib and other event-loop libraries.

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20130506/9148290f/attachment.pgp>