Xlib 和 XCB。 一个进程中有多个窗口。 Xlib 失败而 XCB 没有

Question

不久前，我面临这样一个事实，即在多线程和多窗口的情况下使用Xlib进行编程是一条棘手的道路。 我面临的问题是， Xlib （或窗口管理器）在所谓的“顶级”窗口关闭后强行关闭与服务器的连接。

问题很容易重现，你只需要创建一个窗口，然后关闭它。 尝试在上述步骤后使用Display 。 将引发致命错误并且程序将退出。 这是Xlib的奇怪行为。

问题在几个SO主题中遇到：如何优雅地退出 X11 事件循环？ ，你如何退出X11程序而不出错。 总结讨论，在 Xlib 文档的某处指出 Windows 管理器将关闭连接。

出于好奇，我检查了XCB库是否有这种行为。 与 Xlib 相比， XCB行为“正常”，我能够创建和销毁几个连接仍然存在的窗口。

问题是。 XCB库如何在存在多个窗口和线程的情况下执行，因此它没有显示Xlib错误行为？ XCB在XCB使用Xlib ，还是以其他格式向 X 服务器发送命令？ 请问，我不是很熟悉，如何与X11协议通信。 特别是，窗口管理器如何不关闭与XCB的连接？

我会接受任何能说明问题的答案。 它是指向XCB源代码的网络链接，它解释了做事的聪明方式。 或者是X11协议方面的解释。 或者别的什么。

感谢您的长时间阅读。 我希望我没有让你厌倦所有这些文字。

更新

我把事情搞砸了。 如果在 WM_PROTOCOLS 中设置了 WM_DELETE_WINDOW，则 Xlib 的行为与我预期的一样。 只是排序或同步导致连接处于错误状态。 我认为多个线程以随机方式干扰了Xlib状态，并且事件循环出错了。 我必须警告其他人关于 Xlib，同步应该通过变量或原子原语进行。 Xlib实际状态更改应该只在主线程中并且在事件循环通过之后进行。

Answer 1

总结讨论，在 Xlib 文档的某处指出 Windows 管理器将关闭连接。

“某处”是 Xlib 文档。 你应该更仔细地阅读这些讨论，因为你似乎忽略了一些重要的观点。

XCB 库如何在存在多个窗口和线程的情况下执行，因此它没有显示 Xlib 错误行为？

您可能不喜欢 Xlib 在这方面的行为，但它并不是“错误的”。 它被记录在案，对许多程序都很有用。 此外，虽然关闭连接是关闭顶级窗口时 Xlib 下的默认行为，但这并不是唯一可能的行为。 在您链接的问题的答案中，有一个描述（和文档引用）描述了您需要做的相对简单的事情，以避免在通过关闭按钮关闭顶级窗口时关闭 X 连接。

那么，考虑到我们谈论的是 Xlib 的默认行为，而不是不可避免的行为，XCB 以不同的方式做事也就不足为奇了，因为......

XCB 是在幕后使用 Xlib，还是以其他格式向 X 服务器发送命令？

不，XCB 不使用 Xlib。 它是 Xlib 的替代品，Xlib 是一个年轻的兄弟姐妹，其智慧源于 Xlib 的经验。 Xlib 和 XCB 都通过 X 协议与 X 服务器通信。 ^*它们都是低级的，但 XCB 或多或少是一个直接的协议包装器，而 Xlib 提供了一个 API 外观，隐藏了 X 的客户端/服务器性质。

方向上的差异为窗口关闭按钮的默认行为差异提供了合理的解释。 Xlib 试图猜测 GUI 应用程序的程序员最有可能想要什么，并基于此选择默认值。 大多数 X 应用程序都呈现一个单一的顶级窗口，关闭窗口会终止应用程序，而自动关闭 X 连接对于此类应用程序来说很方便。 另一方面，XCB 不会试图隐藏 X 协议或策略分层（尽管建立在它之上的工具包可能会这样做）。 XCB 就是要对其所做的事情保持透明。

请问，我不是很熟悉，如何与X11协议通信。

一般而言，您使用 Xlib 或 XCB 进行通信。 原则上可以将原始 X11 与 X 服务器对话——毕竟，这就是 Xlib 和 XCB 所做的——但这样做很复杂。 这就是 Xlib 和 XCB 存在的原因。 甚至那些也不是那么容易使用，这就是为什么它们在它们之上构建了更高级别的工具包。

特别是，窗口管理器如何不关闭与 XCB 的连接？

XCB 不指示窗口管理器这样做（至少，默认情况下不是）。 Xlib 也不会这样做，如果您告诉它不要这样做。

---

^*最初是这样。 正如一位评论者所观察到的，如今，Xlib 不直接使用 X 协议，而是使用 XCB（与其他方式相反）。