[Xcb] [RFC] first-class queues

[Daniel Martin]

Hi everyone,

after mailing my ideas on howto:
- fix the full_sequence problem with XGE events,
- expose the 64bit sequence and
- generalize response processing
    http://lists.freedesktop.org/archives/xcb/2013-February/008194.html
Peter Harris pointed me to a proposal on first-class queues, written by
Jamey Sharp in 2010:
    http://lists.freedesktop.org/archives/xcb/2010-September/006480.html
I realy like the idea and I think it has a lot of advantages.

During the last days I thought about it. Now, I would like sum-up and
merge Jameys and my ideas (the biggest part has been laid down by
Jamey). Hopefully, you think that this could be as great as I think it
can be when realized.

The main difference to the current xcb and Xlib approach is that a
client doesn't talk to the connection directly anymore. It works on
queues. It prepares requests in a queue, flushes them explicitly and
picks up the responses and events from a queue.

Jameys idea was to create a request queue and that you've to specify a
response queue for replies and for errors (which could've been the same
response queue). I wouldn't split them and even further I would stuff
events into the same queue (I'll talk about events in response queues
later). Then the client would just do a create_queue() and end up with
a queue having a request (out) and response (in) part.
There'll be a default queue bound to the connection. If the client
doesn't want to create queues, it can operate on this queue. By default
all events will arrive there too.

The request/out queue:
- flushed (written to the connection) explicitly
- possible to "flush without clear" to re-flush a queue more than once
- requests in the queue can be merged (keyword: combine-adjacent)
- requests in the queue should be ready for the wire (no further
  computation necessary, just write them to the socket)
- raw requests (ready for the wire) can be queued directly
- head of the queue keeps track of which request causes a reply to make
  sync decisions before submitting the queue easy
- reqeusts can be removed (might not be that usefull, but should be easy
  to implement)
- flags on requests can be set (i.e. 'discard')

The response/in queue:
- client has to poll for new responses
- a wait_for() should be possible
- possible to register a callback for new responses
- replies, errors _and_ events arrive in this queue, they aren't hard to
  distinguish, we could add a 'type' field to the queue item to help out
- responses can be removed individually and the queue can be cleared at
  once

Events in the response/in queue!
Let's think about a client who would like to have a distinct queue for
RandR stuff. Every request, reply (and error) will be made over this
queue - easy. But, to receive the RandR events there, the client needs
to configure in it some way. This could be done by preparing a (list of)
generic event structure as a filter. Which will be used to compare the
incoming event and if it matches, the incoming event ends up in that
queue.

I think it's still not that clear why I would like to stuff events in
the response queue too. For me they're responses and therefor they
should go in there. It unifies response handling, simplifies the API and
(can't prove that yet) makes everything easier to implement.

Before I'll start I've to:
- read and understand the paper "X meets Z: ..."
- correlate that with the current code
- understand the iovec and think about howto apply it (or a modified
  version) to the request/out queue part
- create a fancy diagram exposing the API (idea)

While writing I should:
- write tests (integrate in XTS or xorg-gtest?)

And tasks that need to be done afterwards:
- port libxcb to use this API
- Jamey proposed it to fix Xlib, so Xlib needs to be ported too

When I sum-up all tasks, it looks like this may take "some time". ;)

Now, it's your turn to stop me from realizing it or to help me clear
things up and create a sane API.


Cheers,
    Daniel Martin
-------------- 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/20130301/4c5b31f5/attachment.pgp>