[Xcb] [Bug 29561] _XReply: performance regression in latest version

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Jamey Sharp <jamey at minilop.net> 2010-08-13 11:28:16 PDT ---
Oh. Every time Xlib calls xcb_wait_for_reply, it has to call xcb_poll_for_event
in case there's an event that should be processed first. Unfortunately, unlike
xcb_poll_for_reply, xcb_poll_for_event tries to read from the socket if it
doesn't find any events to return. I guess that probably seemed like a good
idea to me when I wrote it.

We could get Xlib to call xcb_poll_for_event only once per call to _XReply in
the common case where there are no events, which would improve things for
functions like XInternAtoms that use async replies. It wouldn't help the common
case where async replies aren't being used, though: they'd still have an extra
read syscall per reply.

Ideally we'd change the semantics of xcb_poll_for_event to never read, which
would probably require introducing some sort of xcb_force_read function.
Unfortunately there may be code relying on this side effect of
xcb_poll_for_event, and it's hard to tell which callers care, making that
approach painful. For example, _XEventsQueued in xcb_io.c is relying on this
side effect, but _XReadEvents is not... I think?

The other approach is to introduce a response queue API. Xlib would inform XCB,
"I want all events and any responses to these requests that I issue," and XCB
would feed that set of responses into a queue without separating replies,
errors, or events. Such an API would eliminate a lot of the XCB-related code in
Xlib; fix the one remaining Xlib/XCB threading bug I know about; fix this
excessive-read annoyance; and hopefully turn out to be useful to other callers
too, such as cairo. But somebody needs to write the code.

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