[Xcb] XCBGetRequestRead()

[Jamey Sharp]

On Sun, Apr 16, 2006 at 11:09:54PM -0700, Barton C Massey wrote:
> Other than the horrible name :-), and the lack of an obvious
> use case for the function :-), I'm not seeing what the issue
> is.

Those aren't enough? ... And we let you architect XCB? What were we
thinking?

;-)

> Could you or Josh attach a summary of the
> question/problem to bug #6120, and maybe post it here?
> Inquiring minds want to know!

I think I draft better in e-mail. I'll post here, and maybe it'll
migrate over to the bug too.

The only thing this function is useful/intended for is to check whether
forcing a particular reply cookie would block. Xlib uses it that way,
and my xcb_reply library uses it that way. It's not used by any other
code, as far as I know.

This function doesn't fit the use case for several reasons. It's not
thread-safe, though Josh complained that apps just shouldn't do this
across multiple threads. It's error-prone -- all two calls in current
code are buggy -- because callers have to check if one sequence number
is less than another, and that gets hard at 32-bit wrap. And it answers
the wrong question: it can prove that a call won't block, but it might
incorrectly tell the caller that a call will block when it won't.

Since that's all it's useful for, I think we need a non-blocking variant
of XCBWaitForReply, instead. We already have a non-blocking variant of
XCBWaitForEvent. There are several things that make this complicated
though.

1) Type-safety. XCB*ForEvent uses a generic event pointer type.
XCBWaitForReply uses a void*, but appears only in the extension API and
is intended to be called only by a type-safe wrapper. Simply duplicating
the function in a Poll variant suggests we ought to duplicate all the
type-safe wrappers as well. Obviously we *can* do this, but should we?
On the bright side it only affects requests that have replies, and those
are rarer than the other kind.

2) Return value. We might detect three distinct conditions, and the
caller needs to be able to tell the difference. These are: returned a
reply because one was immediately available; returned nothing because we
would have had to block to return a reply; returned nothing because we
can prove no more responses can come to that sequence number.
XCBWaitForReply only blocks in the second case.

3) Interaction with X error handling. Probably this new function needs
to poll for "either reply or, if requested when enqueueing, error", as
per plan 7.

Uh, does that cover everything?

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060417/39894d25/attachment.pgp