[Xcb] [RFC] first-class queues vs. callbacks

[Daniel Martin]

On Sat, Mar 02, 2013 at 05:21:48PM -0800, Josh Triplett wrote:
> On Sat, Mar 02, 2013 at 09:44:40PM +0100, Daniel Martin wrote:
> > while we are (or I'm) at finding a nice alternative to the current
> > behaviour of xcb I would like to throw in yet another idea. I've talked
> > to a college of mine and he asked: why it has to be queues, why not
> > callbacks?
> 
> Historically, XCB has had an aversion to callbacks, due to the more
> complex control flow, and poor interactions with the locking model.

If we would have an explicit thread waiting for incoming data, which
raises a callback with the new response, we could avoid a lot of
locking. If that response should end up in a queue, we would need an
some locking there. But, imho no wait/poll_for() should set a lock and
wait for IO directly.

> The callback model also doesn't necessarily fit well with toolkits, and
> toolkits represent the primary user of XCB; we don't want to optimize
> specifically for apps written directly on top of XCB.

With the callbacks I had toolkits in mind. For example:
- While constructing (window) objects it appends the requests to the
  queue/batch.
- When the object hierarchy is complete it flushes the queue/batch out.
- (Proceed with usual toolkit stuff, i.e. main loop.)
- Now, the responses float in and callbacks are fired. As a callback has
  the queue/batch and status (and a some private toolkit pointers) as
  payload the toolkit can decide what to do with that. I.e Enqueue it
  somehow into its own main loop.
With that the toolkit wouldn't have to wait or poll for responses - they
"appear" as soon as they arrive. I think that's a great benefit.

> In addition to that, it seems quite simple to build a callback model on
> top of a queue, isolating the complexity in a separate library, and
> allowing users to select between different event models.

I think the other way around might be more simple. If the client wants
to use callbacks, he wants to deal with the data in a more lightweigth
fashion and we don't need a response queue. And if he wants to use
queues, those queues could internally use callbacks too.

While writing this idea about the callbacks, I haven't thought about
providing both models (queues and callbacks). But, you're right. We can
(should?) have both.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20130303/428ba6ed/attachment.pgp>