Is there some Boost functionality for simulating a Glib::Dispatcher?

Question

I am currently in the process of refactoring an mid-sized software project. It contains a central kernel-like class that is used by multiple threads. Currently, this class uses a Glib::Dispatcher for handling signals that are emitted by multiple threads. Since one goal of the refactoring proccess is to get rid of glibmm entirely (since Qt shall be used as the new framework), I am trying to figure out a way of how to "simulate" the dispatcher functionality using Boost. I already looked into Boost.Signals and Boost.Signals2, but neither one of these libraries seems to offer an alternative to the dispatcher.

To clarify what the dispatcher shall do, here's a short description from the official documentation:

Glib::Dispatcher works similar to sigc::signal. But unlike normal signals, the notification happens asynchronously through a pipe. This is a simple and efficient way of communicating between threads, and especially useful in a thread model with a single GUI thread.

No mutex locking is involved, apart from the operating system's internal I/O locking. That implies some usage rules:

• Only one thread may connect to the signal and receive notification, but multiple senders are allowed even without locking.
• The GLib main loop must run in the receiving thread (this will be the GUI thread usually).
• The Dispatcher object must be instantiated by the receiver thread.
• The Dispatcher object should be instantiated before creating any of the sender threads, if you want to avoid extra locking.
• The Dispatcher object must be deleted by the receiver thread.
• All Dispatcher objects instantiated by the same receiver thread must use the same main context.

Could you give me some pointers in the right direction? Is this the sort of functionality I can achieve using Boost.Signals or Boost.Signals2?

Edit: As a commenter rightly pointed out, using Qt would perhaps be an option. However, the class that I am refactoring is very low-level and I do not want to add this additional dependency.

Answer 1

I have now opted for a total rewrite of the class in question. It turns out that I do not require the dispatcher functionality in the way it was provided by Glib. Instead, it was enough to use the normal boost::signals2 signals, coupled with some signals from Qt for the actual graphical interaction.

Answer 2

I think there is no simple way to do that, removing Glib in flavour of boost won't solve the problem which is more an architechtural issue than anything else. Replacing with Boost not gonna fix the design issue. You should model your own signal interface, and try to adapt for each library, including Glib in the first place since it is already working, adding another indirection level to your problem will let you fix that issue.

Boost can help you if you look at boost::function. I dont consider replacing glib with boost to be a real step forward, boost is not a graphical library and it will be required at some point to add an interface with an implementation layer to your graphic engine.