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
.