[Xcb] XCB2 comments

[Peter Harris]

On 2010-09-29 19:48, jamey at minilop.net wrote:
> Here's roughly what I have in mind: first-class request queues and
> response queues.

> When creating a request queue, you specify a response queue for its
> errors and one for its replies. These can optionally be the same queue.

Hmm. I had envisioned that a new response queue would be created every
time you submit ("flush") a request queue. There would be only one
standard queue, the event queue. Errors could optionally go to the
associated reply queue or to the event queue. (Or even automatically
discarded? The combinatorial explosion doesn't hurt as much when it's
only applied to "flush". I'm not sure I want to encourage people to
ignore errors, though.)

I'm not sure "flush" makes sense as a verb if the same request queue can
be sent multiple times (poor-man's DisplayList), but that's just
bikeshedding.

Initially, I thought that request queues would not need to be bound to
any particular connection. Then I realized that extension numbers are
per-display. Neither passing a connection to each extension request nor
rewriting the request queue when flushing sound particularly appealing.

>  For
> convenience, the request queue could provide an allocator for memory
> that will be automatically freed when that queue is flushed.

I presume you meant freed, not flushed, as the request queue itself will
need to be manually freed. Unless flush takes a "free the request queue
now please" parameter, along with all the checked/unchecked
permutations, I suppose.

> xcb_send_request would be reimplemented on top of a pair of request
> queues, one used for checked requests and the other for unchecked
> requests. These request queues would use the standard reply queue for
> all responses

My variation doesn't have a standard reply queue. I have to admit, I
haven't thought out the implications for xcb_send_request.

If xcb2 reply queues are efficient enough, the degenerate case of "one
per checked request" looks a lot like the xcb1 model.

> Open questions:
> 
> We probably need an xcb_discard_response. Does it discard the response
> from a single response queue? from both queues bound in a request queue?
> from all queues bound to a connection?

In this variation, we don't need an xcb_discard_response. xlsclients
would rather discard an entire batch of replies at a time. Language
bindings would garbage collect the entire reply queue when it goes out
of scope, rather than individual replies (since xcb2 wouldn't have the
same kind of per-request cookie that xcb1 does).

(In my variation, reply queues aren't bound to request queues, so
discarding a request queue doesn't do anything to the reply/error queue,
and vice versa).

> How should xcb_wait_for_response return the sequence number of the
> response? Since this is new API we can expose 64-bit sequence numbers.
> I'm inclined to leave the full sequence number out of the response
> structure itself, unlike xcb_generic_event_t, and hand it back as an
> out-parameter of xcb_wait_for_response instead. That way the response
> structure you get back is always *exactly* what came off the wire.

Agreed.

I might restrict wait_for_response to the event queue, and make replies
wait for an entire reply queue at a time. We'd have to teach people not
to put a big GetImage in the same request queue as other needs-reply
requests if they want decent performance.

Maybe I've been hurt by weak allocators on poor OSs, but I'd like to see
an xcb_free_reply_queue boil down to a small handful of free() calls,
not number_of_replies_plus_errors_plus_one.

> If we thought about
> this in terms of designing an "XCB 2.0", and re-implementing XCB 1 as a
> separate library on top, would that change how we do this? For example,
> the standard reply queue might go away.

Ah. So I'm not the only one to have thought of this, then.

> Callers should generally not use xcb_wait_for_response on the default
> event or reply queues, since it isn't thread-safe and those queues are
> shared between all users of that connection.

Hmm? How does one retrieve an event, then? Were you planning to shoehorn
events of a particular sequence range into the reply/error queues?

In my variation, one would use xcb_wait_for_response only on the event
queue (only from one thread, of course. If you want to handle events
from multiple threads, dispatch them yourself. You probably want to do
some sort of "which thread created that window" lookup to determine
which thread wants to handle the event anyway).

xcb_wait_for_queue would be used on reply queues. Cookies retrieved from
adding requests to a request queue would be a simple offset. The queue
knows the 64-bit sequence number to add to the offset (saved at queue
creation time, aka "flush").

Since the reply queue would be read-only, multiple threads could
theoretically access it simultaneously between wait_for and free,
although I'm having a hard time seeing why you would want to (compared
to having each thread handle its own request/reply queues).

> Extensions that might not be justified:
> 
> When you close a response queue, XCB discards all responses for that
> queue, including responses that haven't arrived yet. I think you
> shouldn't be allowed to close the standard event or reply queues. (What
> happens if you close a queue used for replies but not the queue used for
> errors, or vice versa?)

In this variation, closing an "errors sent to the event queue" reply
queue would not affect the errors being sent to the event queue. You
can't close the event queue (without closing the whole connection), so
there is no vice versa.

> Two-stage flush: Provide an alternative flush call that queues the
> requests on the XCB connection but returns without blocking on the
> socket. Return some handle that can be used to find out whether that
> flush is complete, so the caller knows when it's safe to free buffers.

Async IO? I hadn't thought of that. Interesting.

> Obviously I have a lot of thoughts about this proposal. :-) Comments?

Clearly you have put a lot of thought into this. I kept writing and
deleting stuff about Async IO as I tried to wrap my head around it. :-)

Comments provided. Comments?

I haven't looked at cairo yet. Does this variation fit with what they want?

Peter Harris
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866