[Xcb] [Bug 29599] hang in xcb_request_check() due to expecting a reply on void request

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29599

--- Comment #5 from Havoc Pennington <hp at pobox.com> 2010-08-18 14:38:06 PDT ---
btw, I guess it's too late to change the API and this could be an API change,
but I think a nicer way for things to work might be:

 - send a fire-and-forget (discard reply) GetInputFocus anytime we
   flush and there has not been a non-void request since the most
   recent void-and-checked request.

That way, the normal sane usage pattern would Just Work:

 send_nonvoid_request()
 send_void_and_checked_request()
 send_void_request()
 xcb_flush()  /* sends GetInputFocus because void_and_checked with no nonvoid
*/

note that on flush, we would not *block* on the GetInputFocus reply, of course.
We don't care about the reply except to update request_read later.

the GetInputFocus would also be sent on implicit flush (say on xcb_take_socket
or buffer filling up or whatever), so it would always happen eventually.

might send a few more GetInputFocus but that's far less of a problem than
GetInputFocus *round trips* in xcb_request_check

another sane approach I think would just require the app to send a
getinputfocus and warn/complain on stderr if xcb_request_check is invoked
without a non-void request since the void request was sent. i.e. make this the
app's problem and declare it a bug if we get to xcb_request_check and it's
going to hang.

I guess my point is, the blocking GetInputFocus round trip in xcb_request_check
is never really desirable and apps really ought to avoid it or XCB should avoid
it for them.

But, all this is more future enhancement, I know there's a much smaller fix to
the immediate bug here.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.