Signal class for inter-thread communication.
Glib::Dispatcher works similar to sigc::signal<void()>. 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.
Notes about performance:
- After instantiation, Glib::Dispatcher will never lock any mutexes on its own. The interaction with the GLib main loop might involve locking on the receiver side. The sender side, however, is guaranteed not to lock, except for internal locking in the
write() system call.
- All Dispatcher instances of a receiver thread share the same pipe. That is, if you use Glib::Dispatcher only to notify the GUI thread, only one pipe is created no matter how many Dispatcher objects you have.
Using Glib::Dispatcher on Windows:
Glib::Dispatcher also works on win32-based systems. Unfortunately though, the implementation cannot use a pipe on win32 and therefore does have to lock a mutex on emission, too. However, the impact on performance is likely minor and the notification still happens asynchronously. Apart from the additional lock the behavior matches the Unix implementation.
- Examples:
- thread/dispatcher.cc.
