Xlib与XCB多窗口多线程行为差异及XCB实现原理问询

Let’s break this down clearly—your questions get at some core design differences between Xlib and XCB that explain their behavior in complex setups.

Why doesn’t XCB have the same multi-thread/multi-window issues as Xlib? #

Xlib was designed in an era where multi-threaded apps were far less common, and it’s not thread-safe by default. It maintains shared global state tied to the Display handle—things like event queues, request buffers, and error tracking. When you mix threads or multiple windows without strict synchronization, you can easily corrupt this state, leading to invalid operations (like accessing a Display after window resources are cleaned up) that trigger Xlib’s fatal error handler, which terminates your program.

XCB, by contrast, was built from scratch with thread safety in mind. Every XCB operation is a standalone, stateless request to the X server. There’s no shared global state between threads—each thread can manage its own connection context (or share one with minimal sync if needed). Destroying a top-level window just generates a regular event that XCB lets you handle gracefully, no connection termination required.

Is XCB built on Xlib, or does it communicate directly with the X server? #

XCB is a direct, low-level binding to the X11 protocol—it doesn’t depend on Xlib at all. Xlib adds a thick layer of abstraction, caching, and convenience functions on top of the X11 protocol, which is where its shared state baggage comes from. XCB cuts out the middleman: it lets you send raw X11 requests and parse responses directly, making it lighter, more flexible, and less prone to state-related bugs in complex environments.

Why doesn’t the window manager disconnect XCB connections when a top-level window closes? #

The "disconnect" you saw with Xlib isn’t the window manager terminating the connection—it’s Xlib itself. Xlib has a default error handler that calls exit() when it hits certain fatal errors (like trying to use an invalid Display state after window destruction).

XCB doesn’t enforce this aggressive termination. You’re in full control of error handling: you can catch and process errors without killing the entire program. Plus, XCB doesn’t tie window lifecycle to connection state—closing a window sends either a WM_DELETE_WINDOW event (if you’ve set up the protocol) or a DestroyNotify event, neither of which triggers a connection shutdown unless you explicitly close the XCB connection yourself.

Critical Xlib Reminders from Your Updated Findings #

You nailed the root cause of your initial Xlib problem—here’s a clear breakdown for other developers:

• Always handle the WM_DELETE_WINDOW protocol: If you skip this, the window manager may force-close the window in a way that corrupts Xlib’s internal state. Setting up the protocol tells the WM to send your program an event instead, letting you clean up resources gracefully.
• Xlib is not thread-safe: All operations touching the Display handle, modifying window state, or interacting with the event loop must:
  • Run exclusively in the main thread, or
  • Be protected by synchronization primitives (like mutexes) to ensure only one thread accesses Xlib state at a time.
• Sync state changes with the event loop: Multi-threaded interference can break Xlib’s event queue—never modify state until the event loop has processed pending events.

内容的提问来源于stack exchange，提问作者jorge is not ai