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（與其他方式相反）。