Multithreading XInitThreads（）的缺点是什么？

我知道

XInitThreads（）

将允许我从主线程以外的线程调用X服务器，并且如果我想进行调用，Xlib中的并发线程支持是必要的。我对我的应用程序有这样的需求，但在一个非常罕见的情况下。不幸的是，xinithreads（）需要在我的应用程序执行的一开始就被调用，因此会影响我是否需要它来执行特定的运行（在运行应用程序之前，我无法知道我是否需要多线程OpenGL支持）

我很确定，如果我无用地调用xinithread（），应用程序的整体行为将保持不变，但编程都是为了权衡，而且我很确定，多线程支持不是Xlib的默认行为是有原因的

---

表示建议单线程程序不要调用此函数，但没有说明原因。调用XInitThreads（）时有什么折衷

它创建一个全局锁，并且在每个显示器上都创建一个全局锁，因此对Xlib的每次调用都将执行锁定/解锁。如果您改为使用自己的锁（使用自己的锁一次在单个线程中使用Xlib），那么从理论上讲，通过使用锁，一次执行大量Xlib操作，然后放下锁，您可以减少锁定开销。或者在实践中，大多数工具包使用的模型根本不锁定，只要求应用程序仅在主UI线程中使用X

由于许多Xlib调用被阻塞（它们等待服务器的回复），所以锁争用可能是一个问题

在显示每个Xlib调用时锁定也有一些语义上的问题；在线程A上的每次Xlib调用之间，理论上任何其他Xlib调用都可以在线程B上进行。因此，线程可以相互踩踏以混淆显示状态，即使一次只有一个线程发出Xlib请求。也就是说，XInitThreads（）可以防止由于并发显示访问而导致的崩溃/损坏，但它实际上没有考虑让多个线程共享一个X服务器连接的任何语义考虑

我认为需要从并发显示访问中获得自己的语义，这是人们不必为XInitThreads per Xlib调用锁定而烦恼的一个原因。因为它们最终都会得到应用程序级或工具箱级的锁

这里的一种方法是在每个线程中打开一个单独的显示连接，这取决于您正在做什么

另一种方法是使用较新的xcb API，而不是Xlib；xcb从头开始设计为多线程和非阻塞

历史上，在某些OS/Xlib版本的XInitThreads（）中也存在一些bug，尽管我不记得任何细节，但我确实记得看到过这些bug