glibmm 2.64.2

- Main Page
- Related Pages
- Modules
- Namespaces
- Classes
- Examples

- Class List
- Class Index
- Class Hierarchy
- Class Members

Public Member Functions | List of all members
Glib::Dispatcher Class Reference
Threads

Signal class for inter-thread communication. More...

`#include <glibmm/dispatcher.h>`

## Public Member Functions
| Dispatcher ()
| Create new Dispatcher instance using the default main context. More...
| Dispatcher (const Dispatcher&)=delete
Dispatcher& | operator= (const Dispatcher&)=delete
| Dispatcher (const Glib::RefPtr< MainContext >& context)
| Create new Dispatcher instance using an arbitrary main context. More...
| ~Dispatcher () noexcept
void | emit ()
void | operator() ()
sigc::connection | connect (const sigc::slot< void >& slot)
sigc::connection | connect (sigc::slot< void >&& slot)

## Detailed Description

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.

## Constructor & Destructor Documentation

Glib::Dispatcher::Dispatcher | ( |  | ) |

Create new Dispatcher instance using the default main context.

Exceptions

  Glib::FileError |

Glib::Dispatcher::Dispatcher | ( | const Dispatcher& |  | ) |
| delete

Glib::Dispatcher::Dispatcher | ( | const Glib::RefPtr< MainContext >& | context | ) |
| explicit

Create new Dispatcher instance using an arbitrary main context.

Exceptions

  Glib::FileError |

Glib::Dispatcher::~Dispatcher | ( |  | ) |
| noexcept

## Member Function Documentation

sigc::connection Glib::Dispatcher::connect | ( | const sigc::slot< void > & | slot | ) |

sigc::connection Glib::Dispatcher::connect | ( | sigc::slot< void > && | slot | ) |

Since glibmm 2.48:

void Glib::Dispatcher::emit | ( |  | ) |

void Glib::Dispatcher::operator() | ( |  | ) |

Dispatcher& Glib::Dispatcher::operator= | ( | const Dispatcher& |  | ) |
| delete