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

[Bart Massey]

I think callbacks are a prime example of why implementing anything
above the kernel level in C is a terrible plan. The lack of automatic
closure capture means that you end up passing a bunch of error-prone
handles around for various "user data", and the lack of automatic
memory management means that the callbacks leak this data like a sieve
and/or dereference bogus pointers. The "who's on first" confusion
about what data is shared by which threads of execution becomes a real
problem.

That said, I think the lack of toolkit adoption of XCB somewhat speaks
for itself. If callbacks are what toolkits need to move to XCB, we
should give them callbacks. But I definitely think it should be driven
by specific toolkit plans, not by speculation about what toolkits
might like. My suspicion is that a lack of callbacks is not the
biggest XCB issue in the way of the toolkit developers.

--Bart

On Sun, Mar 3, 2013 at 1:05 AM, Daniel Martin <consume.noise at gmail.com> wrote:
> 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.
>
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb