我知道XInitThreads()将允许我从主线程以外的线程调用X服务器，如果我想创建OpenGL calls from secondary threads using Qt，那么Xlib中的并发线程支持是必要的。我对我的应用程序有这样的需求，但是在非常罕见的情况下。不幸的是，XInitThreads（）需要在应用程序执行的最初阶段调用，因此对于特定的运行是否需要它会影响它（如果我需要多线程OpenGL，我在运行应用程序之前无法知道）支持与否）。
我很确定如果我无用地调用XInitThread（），应用程序将保持不变的整体行为，但编程完全是权衡，我很确定多线程支持不是Xlib的默认行为
The man page表示建议单线程程序不要调用此函数，但它没有说明原因。调用XInitThreads（）时的权衡是什么？
答案 0 :(得分：12)
它会在每个人机界面上创建一个全局锁定，因此每次调用Xlib都会锁定/解锁。如果您改为自己进行锁定（使用自己的锁保持Xlib一次使用在一个线程中），那么理论上你可以通过锁定，一次执行大量Xlib内容然后丢弃来减少锁定开销。你的锁。或者在实践中，大多数工具包使用的模型根本不会锁定，只需要应用程序仅在主UI线程中使用X.
由于许多Xlib调用都在阻塞（他们等待来自服务器的回复），因此锁定争用可能是一个问题。
在Display上锁定per-Xlib-call也会有一些语义上的痛苦;在线程A上的每个Xlib调用之间，理论上任何其他Xlib调用都可以在线程B上进行。因此线程可以在混淆显示状态方面相互踩踏，即使其中只有一个一次发出Xlib请求。也就是说，XInitThreads（）可以防止由于并发显示访问而导致的崩溃/损坏，但它并没有真正处理让多个线程共享X服务器连接的任何语义考虑因素。
我认为需要通过并发显示访问来创建自己的语义感，这是人们不会为XInitThreads per-Xlib-call锁定而烦恼的一个原因。因为无论如何他们最终会得到应用程序级别或工具包级别的锁定。
这里的一种方法是在每个线程中打开一个单独的显示连接，这取决于你正在做什么。
另一种方法是使用较新的xcb API而不是Xlib; xcb从头开始设计为多线程和非阻塞。
历史上，在某些OS / Xlib版本中，XInitThreads（）中也存在一些错误，但我不记得任何细节，我确实记得看到过那些错误。