我正在将现有的一些软件从macOS和Windows移植到Linux。该软件的基础是在GUI后面运行的多线程服务器，该服务器显示统计信息，针对特定事件生成新窗口，等等。
在macOS上，我们有DispatchQueue.main.sync。在Windows / C＃/ WPF上，我们有Dispatcher.Invoke。我们专门在需要在更新UI线程时阻塞调用线程的情况下使用这些调用。 GTK +是否有类似的功能？
我一直在将gdk_thread_add_idle_full用于不需要阻塞的代码的异步部分，但是对于同步版本，它要复杂一些。我当前的解决方案是一个包含GMutex / GCond对的简单对象。该对象在调用线程上是“等待”的，在UI线程上是“ completeable”的。将此对象传递给gdk_thread_add_idle_full可以达到预期的效果，但我很好奇是否有更简洁的选择。
服务器库是原样的，因此没有空间修改该代码以使其表现更好。我正在寻找工具箱方面的解决方案。另外，GTK +的工作全部在C中完成。
我认为没有更简洁的选择，使用GMutex / GCond对似乎可以使工作线程与UI线程的回复保持同步。
使用GMutex / GCond对的不利之处在于，这意味着您无法同时在工作线程上迭代GMainContext。如果那不是您的应用程序的构造方式，那很好。
[如果是，那么您可能想采用一种方法，将对辅助线程的GMainContext的引用传递给gdk_threads_add_idle_full()调用中的UI线程。 UI操作完成后，UI线程中的代码将在工作线程的g_idle_source_new()上调用g_source_attach() / GMainContext，以安排要在工作线程中执行的回调。此回调将更新状态以将操作标记为完成并返回。
在这种方法中，gdk_threads_add_idle_full()和g_idle_source_new() / g_source_attach()本质上都是从一个线程到另一个线程的消息传递函数。在您的方法中，GMutex / GCond替代地充当了同步屏障。
这第二种方法意味着您的工作线程可以在等待UI时继续其他有用的工作，而不是阻塞。但这可能与应用程序的构造无关。