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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #3 from Robert White <rwhite at pobox.com> 2010-12-04 09:05:41 PST ---
Possibly super niave question: Why not split xcb_poll_for_event into an
internal and a wrapper. The wrapper would contain the whole implementation
as-is by being a call to the internal (say xcb_check_for_buffered_events) and
then try the file descriptor once if the check returned nada.

Now xcb_wait_for_reply could also call xcb_check_for_buffered_events before
going into its poll/wait/whatever; which will naturally already have the path
to include the socket in its wait-for-read list. (If it doesn't already include
the socket that xcb_poll_for_event does the non-blocking read upon, then this
could deadlock anyway, or it is already ready to absorb the hit for unread
events that could happen after xcb_poll_for_event EAGAIN(ed) anyway. In either
case it has zero repeatable impact to skip the actual/expensive failed read.)

The always-oughta rules for poll safe polling are:
(1) you have to check your pre-read data before it is safe to call poll/epoll,
and (2) you always-oughta include all the file descriptors that can feed the
pre-read data pool you check before a poll in the poll itself.

Every path that looks like
"buffer_check-maybe_return-nb_read_into_buffer-maybe_return-poll-nb_read_into_buffer-maybe_return"
is a priori wrong compared to
"buffer_check-maybe_return-poll-nb_read_into_buffer-maybe_return".

So split out the buffer check part of xcb_poll_for_event. Now you don't need a
whole buffer select API, you just process what you got or you poll-wait if you
got nothing buffered. You do this buffer check for all paths, and you decide to
read/poll only once on any path.

-- 
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.