[Xcb] Feature Request: Function "xcb_test_for_event"

[Josh Triplett]

On Wed, Apr 10, 2013 at 05:08:30PM -0700, Bart Massey wrote:
> 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?

That's what you do if you build your application specifically on XCB.
When building a generic event loop, you block until you have data from
any source.  And I can understand wanting to keep all the processing in
a single thread; it seems like a waste to read out an event from XCB,
stuff it in a queue or mailbox, and process it in another thread, if you
could just have XCB unblock you when you have an event.  (Also, you'd
have to do that cross-thread communication for every event, to avoid
getting events out of order.)

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

You seem to have a different definition of "mystic" than I do; I like
the poll() interface quite a bit, and I don't see anything particularly
magic about it.  The two big reasons I prefer select() or poll():

1) I do multithreading for performance; if I don't have a
CPU-bound-performance requirement that demands multiple threads, I'll
always choose an unthreaded solution for simplicity if I can.

2) C.  In a language that had first-class support or standard libraries
for semaphore-locked mailboxes, queues, or other nice multithread-safe
data structures, I might consider using them.  In C, unless I have
performance reasons to need to use multiple threads (see #1), I'll
choose something in libc that has worked since the dawn of POSIX over
something I either have to reimplement in my own codebase or pull in
another library dependency for.

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

So does Xlib.

> Does this sound like what people want?

"want" seems like such a strong word.  It seems like the least insane
way to do this, if we want it, but I don't feel a strong desire to add
it unless one of the major toolkits tells us they'd actually use it.

- Josh Triplett