[Xcb] [Bug 51648] xcb calls read(2) to test data availability on xorg sockets instead of polling on FreeBSD

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jul 2 03:48:26 PDT 2012


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

Uli Schlachter <psychon at znc.in> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Uli Schlachter <psychon at znc.in> 2012-07-02 03:48:26 PDT ---
There are just two callers of _xcb_in_read(). _xcb_conn_wait() first does the
needed poll(), so shouldn't cause any EAGAINs. Other caller is
poll_for_next_event() when called via xcb_poll_for_event(). So in this case,
the caller of xcb_poll_for_event() asked us to check if any new events are
ready, so checking via read() is the right thing to do. The EAGAIN that we get
back is read()'s way of saying "nope, no new event".

So if you see lots of EAGAINs from _xcb_in_read(), something (Xlib?) is doing
lots of xcb_poll_for_event() calls.

What effect would adding a call to poll() here have? That's just an extra
syscall and thus can only slow down things.

On your question: Yes, since this is expected behavior, I bet this happens on
Linux, too. However, why do you call this an issue? What's wrong with this?
Also, since when do syscall failures shorten the batter life "and drain[s]
other resources"?

(I won't comment on your patch adding a poll()-call :-) )

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


More information about the Xcb mailing list