[Xcb] [PATCH v2 libxcb] Prevent reply waiters from being blocked.

[Josh Triplett]

On Fri, Oct 08, 2010 at 03:11:04PM +0300, Rami Ylimäki wrote:
> It's possible to call xcb_wait_for_reply more than once for a single
> request. In this case we are nice and let reply waiters continue so
> that they can notice that the reply is not available
> anymore. Otherwise an event waiter could just signal the reply waiter
> that got its reply to continue but leave a waiter for an earlier reply
> blocked.
> 
> Below is and example sequence for reproducing this problem.
> 
> thread #1
>   - waits for events
> thread #2
>   - executes request #2
>   - waits for reply #2
> thread #1
>   - reads reply #2
>   - signals waiter of reply #2 to continue
>   - waits for events
> thread #2
>   - handles reply #2
> thread #3
>   - executes request #3
>   - waits for reply #2
> thread #1
>   - reads reply #3
>   - nobody is waiting for reply #3 so don't signal
>   - wait for events
> 
> Of course it may be questionable to wait for a reply twice, but XCB
> should be smart enough to let clients continue if they choose to do
> so.

I don't know that it makes sense to support a client misbehaving in that
way.  For one thing, how do you tell the difference between such a read
and a read of a future post-sequence-wrap cookie with the same value?
For another, how does this work with multi-reply requests like
ListFontsWithInfo?

Do you have a real-world example of a client that waits for the same
reply multiple times?

- Josh Triplett