是否有一些用于模拟Glib :: Dispatcher的Boost功能？

Question

我目前正在重构一个中等规模的软件项目。它包含一个由多个线程使用的中央内核类。目前，该类使用Glib::Dispatcher来处理多线程发出的信号。由于重构过程的一个目标是完全摆脱glibmm（因为Qt将用作新框架），所以我试图找出如何使用Boost“模拟”调度程序功能的方法。我已经看过Boost.Signals和Boost.Signals2，但这些库中的任何一个似乎都不能提供调度程序的替代方案。

为了澄清什么，调度员应做的，这里有一个简短的描述从the official documentation：

油嘴::调度员的工作原理类似于sigc ::信号。但与 正常信号不同，通知通过 管道异步发生。这是一种在线程之间进行通信的简单高效的方式，并且在具有单个GUI的线程模型中特别有用。

除了操作系统的 内部I/O锁定之外，不涉及互斥锁。这意味着一些使用规则：

• 只有一个线程可以连接到信号并接收通知，但多个 发送者被允许，即使没有锁定。
• GLib主循环必须在接收线程中运行（这通常是GUI线程）。
• Dispatcher对象必须由接收者线程实例化。
• 如果您想避免额外锁定，则应在创建任何发件人线程之前实例化Dispatcher对象。
• Dispatcher对象必须被接收者线程删除。
• 由同一接收者线程实例化的所有分派器对象必须使用相同的主要上下文 上下文。

你能给我一些正确的方向指针吗？这是我可以使用Boost.Signals或Boost.Signals2实现的功能吗？

编辑：作为评论者正确指出，使用Qt也许是一种选择。但是，我正在重构的类是非常低级的，我不想添加这个额外的依赖项。

Answer 1

我现在选择了全班重写有关课程。事实证明，我做而不是需要调度程序的功能，它的方式是由Glib提供。相反，使用正常的boost::signals2信号，加上来自Qt的一些信号用于实际的图形交互就足够了。

Answer 2

我认为没有简单的方法可以做到这一点，在提升风味的情况下去除Glib并不能解决比其他任何问题更多的构架问题。用Boost替代不会解决设计问题。 你应该为自己的信号接口建模，并尝试适应每个库，包括Glib，因为它已经在工作，为问题添加另一个间接级别可以解决这个问题。

如果你看看boost::function，Boost可以帮助你。我不考虑用boost来取代glib是一个真正的进步，boost并不是一个图形库，它会在某些时候需要添加一个带有实现层的接口到你的图形引擎。