[Xcb] Doubled API size
pharris at opentext.com
Wed Dec 23 12:32:32 PST 2009
Jamey Sharp wrote:
> However, I've been toying with the idea of constructing a
> non-thread-safe request queue (call it a request context?) from an
> xcb_connection_t. Sequence numbers wouldn't be assigned until you
> flush the local request queue to the socket, and replies would be
> fetched from the request context.
The more I think about this, the more I like it.
If a 'request context' not associated with any connection is the only
way (outside of socket handoff) to issue requests, it becomes obvious
and clear that you have to submit your context to the connection before
calling wait_for_event. (This isn't a dig at chrysn - I've been bitten
by wait_for_event not flushing more than once).
Allow a context (with no reply-expecting requests in it) to be sent
multiple times, and we have a poor-man's glCallList equivalent.
> "Checked" becomes a property of the
> request context, not the individual request.
> On those occasions where an application needs to issue a request and
> then find out exactly which error occurred in response, I guess you
> could construct a request context to use for just that request, then
> discard it after getting the reply or error.
That would work. Alternatively, an app that really cared could remember
the offset of each request in the context. Given the sequence number of
the submitted context, and the sequence number of the error, it should
be trivial to look up. It means a bit more bookkeeping, but you only
have to pay for it if you want it.
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
More information about the Xcb