Xlib and XCB. Multiple windows in one process. Xlib fails whereas XCB do not

Question

Not so long ago, I was faced with a fact that programming with Xlib in the presence of multiple threads and multiple windows is a thorny path. The problem I was faced with is that, that Xlib (or window manager) is forcefully closes a connection to the server after so called "top level" window is closed.

The problem is easy to reproduce, you just need to create a window, then close it. Try to use use a Display after the above steps. The fatal error will raise and program will exit. This is a strange behaviour of Xlib .

The problem were faced in several SO topics: How do I gracefully exit an X11 event loop? , How do you exit X11 program without Error . To summarize the discussions, It is noted somewhere in Xlib documentation that windows manager will close the connection.

Out of curiosity I checked XCB library for such behaviour. The XCB , compared to Xlib, behaved "normally" and I was able to create and destroy several windows with connection still in place.

The question is. How does XCB library performs in the presence of multiple windows and threads, so it does not show the Xlib faulty behaviour? Does the XCB uses Xlib under the hood, or does it sends commands to the X server in some other format? Excuse me, I am not so familiar, how to communicate to X11 protocol. And in particular, how it come, that window manager does not close the connection with XCB ?

I will accept any answer that will shred a light on the matters. Will it be web-links to XCB source code, that explains the smart way of doing things. Or will it be explanation in terms of X11 protocol. Or anything else.

Thanks for the long reading. I hope I did not tire you with all this text.

Update

I've messed things up. The Xlib behaves as I expect, if WM_DELETE_WINDOW is set in WM_PROTOCOLS. It is just the ordering, or syncing, caused the connection to be in wrong state. I think that multiple threads have interfered with Xlib state in a random way and the event loop got wrong. I must warn others about Xlib, that a syncing should be made by means of variables or atomic primitives. The Xlib actual state change should be made only in the main thread and after the event loop had passed .

Answer 1

To summarize the discussions, It is noted somewhere in Xlib documentation that windows manager will close the connection.

With "somewhere" being the Xlib documentation. And you should read those discussions more carefully, because you seem to have overlooked some important points.

How does XCB library performs in the presence of multiple windows and threads, so it does not show the Xlib faulty behaviour?

You may not like Xlib's behavior in this area, but it is not "faulty". It is documented, and it is useful for many programs. Moreover, although closing the connection is the default behavior under Xlib when a top-level window is closed, it is not the only possible behavior. Among the answers to the questions you linked, there is a description (and documentation citation) describing the relatively simple thing you need to do to avoid the X connection being closed when a top-level window is closed via its close button.

Considering, then, that we're talking about a default behavior of Xlib, not an unavoidable one, it should not be overly surprising that XCB does things differently, because ....

Does the XCB uses Xlib under the hood, or does it sends commands to the X server in some other format?

No, XCB does not use Xlib. It is an alternative to Xlib, a younger sibling written with wisdom that came from experience with Xlib. Both Xlib and XCB communicate with the X server via the X protocol. ^* They are both low-level, but XCB is more or less a straight protocol wrapper, whereas Xlib presents an API facade hiding X's client / server nature.

And that difference in orientation presents a plausible explanation for the difference in default behavior with respect to window-close buttons. Xlib tries to guess what the programmer of a GUI application is most likely to want, and it chooses defaults based on that. Most X applications present a single top-level window, where closing the window terminates the application, and closing the X connection automatically is a convenience for such applications. XCB, on the other hand, doesn't attempt to hide the X protocol or to layer on policy (though toolkits built on top of it may do). XCB is all about being transparent about what it does.

Excuse me, I am not so familiar, how to communicate to X11 protocol.

Generally speaking, you communicate by using Xlib or XCB. It is possible in principle to speak raw X11 to an X server -- after all, that's what Xlib and XCB do -- but doing so is complicated. That's why Xlib and XCB exist. And even those are not so easy to use, which is why they have higher-level toolkits built on top of them.

And in particular, how it come, that window manager does not close the connection with XCB?

XCB does not instruct the window manager to do so (at least, not by default). Xlib doesn't do so either, if you tell it not to do.

---

^* Or so it was initially. As one commenter observed, these days, Xlib does not speak the X protocol directly, but rather uses XCB (as opposed to the other way around).