[Xcb] Feature Request: Function "xcb_test_for_event"

[Bart Massey]

On Wed, Apr 10, 2013 at 11:45 AM, Josh Triplett <josh at joshtriplett.org> wrote:
> On Wed, Apr 10, 2013 at 10:39:19AM -0700, Bart Massey wrote:
>> On Tue, Apr 9, 2013 at 2:00 PM, Josh Triplett <josh at joshtriplett.org> 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.

Help me understand. One of the principles of XCB is that you don't ask
for an answer until you want the answer, at which point XCB will block
exactly until the answer is available, then return it to you. Why is
that wrong?

>> 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.
>
> Even with all the experience I have doing and researching multithreaded
> programming, I'd still always choose to use select() or poll() over any
> kind of shared-memory data structure, if I have the option. :)

Why?? I really don't get it. A semaphore-locked mailbox (which is all
you need, really--a queue is overkill) is one of those data structures
that you *must* have lying around for multithreaded programming.
Implementing it is crazy easy, using it is crazy easy, examining it is
crazy easy, and debugging it is crazy easy. The OS doesn't get
involved, so there's no mystic behaviors.

For single-threaded single-process programming, you're stuck with
select()/poll(). In this situation, your options are much tougher with
XCB; we never figured out any sensible way to select() on an event.
I'm not sure how much we can do about this; various semi-crazy schemes
come to mind.

I guess that the least obnoxious (maybe) of these is to allow the
client to call xcb_wait_for_something() with "extra" fds; the call
would return when an event was available or one of the extra fds went
live. XCB could sit blocked in select()/poll() processing replies
until either an event is ready or an extra fd is ready. Xt had
something vaguely like this.

Does this sound like what people want?

--Bart