1. 21 Sep, 2015 2 commits
  2. 21 May, 2014 1 commit
  3. 23 Jan, 2012 1 commit
  4. 19 Aug, 2010 1 commit
    • Aaron Plattner's avatar
      XOpenDisplay: save the correct display_name value · f92e7542
      Aaron Plattner authored
      The X Test Suite's XDisplayString test checks the invariant
      XDisplayString(XOpenDisplay(str)) == str.  The Xlib XOpenDisplay violates this
      invariant by expanding str to the canonical form "host:display.scrn" (unless
      HAVE_LAUNCHD is set and it starts with "/tmp/launch").  E.g., this expands ":1"
      to ":1.0":
      
        400|26 1 1 19:26:41|IC Start
        200|26 1 19:26:41|TP Start
        520|26 1 00032625 1 1|VSW5TESTSUITE PURPOSE 1
        520|26 1 00032625 1 2|Assertion XDisplayString-1.(A)
        520|26 1 00032625 1 3|A call to XDisplayString returns the string that was used
        520|26 1 00032625 1 4|as the argument to the XOpenDisplay call that returned the
        520|26 1 00032625 1 5|value used as the display argument.
        520|26 1 00032625 1 6|METH: Open a connection using XOpenDisplay.
        520|26 1 00032625 1 7|METH: Obtain the display string using XDisplayString.
        520|26 1 00032625 1 8|METH: Verify that the value of the string is the parameter used in XOpenDisplay.
        520|26 1 00032625 1 9|METH: Close the display using XCloseDisplay.
        520|26 1 00032625 1 10|REPORT: XDisplayString() returned ":1.0" instead of ":1".
        220|26 1 1 19:26:41|FAIL
        410|26 1 1 19:26:41|IC End
      
      Fix this by deleting all of the code to construct the canonical path and just
      stashing a copy of the original display_name in dpy->display_name.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Jeremy Huddleston Sequoia's avatarJeremy Huddleston <jeremyhu@apple.com>
      f92e7542
  5. 18 Apr, 2010 2 commits
    • Jamey Sharp's avatar
      Fix Xlib/XCB for multi-threaded applications (with caveats). · 933aee1d
      Jamey Sharp authored
      Rather than trying to group all response processing in one monolithic
      process_responses function, let _XEventsQueued, _XReadEvents, and
      _XReply each do their own thing with a minimum of code that can all be
      reasoned about independently.
      
      Tested with `ico -threads 20`, which seems to be able to make many
      icosahedrons dance at once quite nicely now.
      
      Caveats:
      
      - Anything that was not thread-safe in Xlib before XCB probably still
        isn't. XListFontsWithInfo, for instance.
      
      - If one thread is waiting for events and another thread tries to read a
        reply, both will hang until an event arrives. Previously, if this
        happened it might work sometimes, but otherwise would trigger either
        an assertion failure or a permanent hang.
      
      - Versions of libxcb up to and including 1.6 have a bug that can cause
        xcb_wait_for_event or xcb_wait_for_reply to hang if they run
        concurrently with xcb_writev or other writers. So you'll want that fix
        as well.
      Signed-off-by: Jamey Sharp's avatarJamey Sharp <jamey@minilop.net>
      Reviewed-by: Josh Triplett's avatarJosh Triplett <josh@freedesktop.org>
      933aee1d
    • Jamey Sharp's avatar
      Pending requests are always added in-order. · f2735889
      Jamey Sharp authored
      Replace insert_pending_request, which did an in-order search of the
      queue to find the right insertion point, with a simpler
      append_pending_request, and use that in _XSend as well.
      
      Includes assertions to check that the list of pending requests is in
      order by sequence number and does not have duplicates.
      Signed-off-by: Jamey Sharp's avatarJamey Sharp <jamey@minilop.net>
      Reviewed-by: Josh Triplett's avatarJosh Triplett <josh@freedesktop.org>
      f2735889
  6. 04 Nov, 2008 2 commits
    • Keith Packard's avatar
      Permit only one Xlib thread to block waiting for events · bedfe682
      Keith Packard authored
      As Xlib queues events internally, we must prevent multiple Xlib threads from
      entering XCB to wait for an event in case the queued event is to be
      delivered to the thread which didn't manage to read it. In other words, let
      only one Xlib thread into xcb_wait_for_event at a time.
      
      Jamey Sharp looked over my shoulder while making this fix and, while hating
      my whitespace conventions, appears happy enough with the actual code.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      bedfe682
    • Josh Triplett's avatar
      Use XCB's new socket handoff mechanism rather than the old XCB Xlib lock. · 54e5c094
      Josh Triplett authored
      Previously, Xlib/XCB used XCB's Xlib lock to prevent XCB from sending
      requests between calls to Xlib's LockDisplay and UnlockDisplay macros.
      Xlib/XCB then sent all of its requests using XCB's xcb_send_request, and
      had to flush its requests when unlocking the display.
      
      XCB 1.2 adds a new socket handoff mechanism, xcb_take_socket.  Replace
      much of the existing Xlib/XCB implementation with the use of
      xcb_take_socket to take ownership of the write side of the X connection
      socket, and a return_socket callback which writes any outstanding requests
      with xcb_writev.  This approach allows Xlib/XCB to use the same buffering
      as traditional Xlib did.  In particular, programs which use Xlib/XCB and
      never make XCB calls will never need to hand the socket back to XCB, and
      vice versa.
      
      This allows us to discard large quantities of synchronization code from
      Xlib/XCB, together with the synchronization bugs present in that code.
      Several test cases which previously failed now work perfectly, including
      multi-threaded ico.  In addition, the infamous locking correctness
      assertions, triggered when double-locking or when unlocking without a
      previous lock, no longer exist, because Xlib/XCB no longer has any reason
      to care more about application locking than traditional Xlib does.
      
      Furthermore, the handoff approach provides great improvements to
      performance.  Results from x11perf's XNoOp test, which represented the
      worst case for the lock-based Xlib/XCB:
      
      Traditional Xlib:       average 19100000/sec
      Lock-based Xlib/XCB:    average  3350000/sec
      Handoff-based Xlib/XCB: average 17400000/sec
      
      Thus, for no-ops, the handoff mechanism provides more than a 4x speedup to
      Xlib/XCB, bringing Xlib/XCB within 9% of traditional Xlib no-op
      performance.  Of course, real-world workloads do not use no-op, so your
      mileage may vary.  In particular, since no-ops represent the worst case,
      we expect real workloads to more closely match the performance of
      traditional Xlib.
      
      While removing synchronization code, we changed _XReply to not drop any
      locks when calling xcb_wait_for_reply; previously, we had to carefully
      avoid a deadlock between the Display lock and the XCB Xlib lock. Holding
      the locks reduces implementation complexity and should not impact
      applications.
      
      Commit by Jamey Sharp and Josh Triplett.
      XCB's handoff mechanism inspired by Keith Packard.
      54e5c094
  7. 28 Mar, 2007 1 commit
  8. 18 Nov, 2006 1 commit
    • Jamey Sharp's avatar
      Bug #8622: Fix response processing order for threaded apps · 67abe024
      Jamey Sharp authored
      Previously, process_responses (the common code for _XReply,
      _XReadEvents, and _XEventsQueued) took the current request sequence
      number as an argument, and did some highly complicated processing to
      attempt to process responses in order across threads.  This didn't
      actually work.
      
      Now, process_responses handles responses in order, by adding condition
      variables to the list of outstanding requests in
      dpy->xcb->pending_requests, and blocking on them when those requests
      should get processed to allow _XReply to process them; if actually
      called from _XReply, it returns when _XReply's request should get
      processed.  _XReply broadcasts on the condition variable after it has
      read its reply and re-acquired the display lock.
      
      Another great commit brought to you by Jamey Sharp, Josh Triplett, the
      Gobby collaborative text editor, conspy, and ridiculous amounts of SSH
      forwarding.
      Signed-off-by: Josh Triplett's avatarJosh Triplett <josh@freedesktop.org>
      Signed-off-by: Jamey Sharp's avatarJamey Sharp <jamey@minilop.net>
      67abe024
  9. 06 Oct, 2006 2 commits
  10. 05 Oct, 2006 1 commit
  11. 04 Oct, 2006 1 commit
  12. 25 Sep, 2006 1 commit
  13. 01 Jul, 2006 1 commit
  14. 08 May, 2006 1 commit
  15. 01 Apr, 2006 1 commit
  16. 21 Feb, 2006 1 commit
  17. 19 Feb, 2006 1 commit