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

[Daniel Martin]

Hi everyone,

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?

A response/in queue still has the drawback - if realized without
_callbacks_ - that you've to poll for responses and that's something we
can avoid.


Events & callbacks

- If you want to receive events, you register a callback.
- If you haven't registered a (matching) callback for events, they'll
  get discarded.
- It should be possible to register different callbacks. Events are
  unique and won't be passed to multiple callbacks. But, while
  registering a callback one should be able to pass a filter for the
  events this callback should be called on.

-> With that we wouldn't need a queue/cache for events where the
   client needs to poll from.


Request queue / batch (of requests)

This part of the initial proposal should be kept. But, as we don't have
a response/in queue within this approach, we need/can treat it a bit
differently. I'll call it batch (of requests) subsequently.
At the beginning such a batch will be used to queue the requests, at one
point it'll be flushed to the X server by the client and after that
it'll be reused to link in the responses.

- It's basicly a batch of requests. Such a batch has to be flushed
  explicitly to the X server.
- When creating a batch you've to specify a callback, which will get
  called for the responses (replies and errors) of that batch and when
  the batch enters the state RCVD or ERR.
- A batch has different states:
  * INIT: The initial state. You can append requests only in this state.
  * SEND: All requests have been send.
  * RCVD: All responses have been arrived.
  * ERR : All responses have been arrived, at least one caused an error.
- A request in a batch has different states:
  * INIT: The initial state.
  * SEND: The request has been send.
  * RCVD: The reply arrived and is linked to this request now.
  * ERR : The request caused an error. This error is linked to this
          request now.
- A wait_for() could be realized by "watching" the state condition of
  the batch.

Workflow:
- The client creates a batch (with a callback).
- Now, the client can append requests and may modify them. I.e. it could
  set the flag 'discard' for a request, then every response (reply or
  error) will be dropped on arrival.
- When the client flushes the batch, the sequence numbers will be set in
  the batch for every request and the batch changes to the SEND state.
- When a response arrives, the corresponding request in the batch will
  change it's state to RCVD or ERR. The callback will be triggered
  (possible arguments: the batch, the request in the batch, the state of
   that request).
- When all responses of a batch arrived, the batch will change its state
  to RCVD or ERR, the callback will be triggered (possible arguments:
  the batch, NULL (request parameter) and the state of the batch).
- Now (final callback), the client knows that all requests have been
  answered, it knows the total state of the batch and it can proceed
  doing what it wants to do.
- One thing it could do is: Reset the batch, which will free all
  responses, sets every state to INIT. BUT, keeps the requests for a
  reflush.

-> With that kind of a batch we wouldn't have any copy operation. We
   would just throw pointers around.


I think that's it for now,
    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/20130302/071a3460/attachment.pgp>