# Glib::Dispatcher Class Reference
[Threads]

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

Collaboration diagram for Glib::Dispatcher:
[legend]

List of all members.

## Public Member Functions

| Dispatcher ()
| Create new Dispatcher instance using the default main context.
| Dispatcher (const Glib::RefPtr< MainContext >& context)
| Create new Dispatcher instance using an arbitrary main context.
| ~Dispatcher ()
void | emit ()
void | operator() ()
sigc::connection | connect (const 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.

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 Glib::RefPtr< MainContext >& | context | ) | `[explicit]`

Create new Dispatcher instance using an arbitrary main context.

Exceptions:

  | Glib::FileError |

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

## Member Function Documentation

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

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

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

The documentation for this class was generated from the following file:

- glibmm/dispatcher.h