<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Using Glib::Dispatcher</title> <link rel="stylesheet" type="text/css" href="style.css"> <meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> <link rel="home" href="index.html" title="Programming with gtkmm 3"> <link rel="up" href="chapter-multi-threaded-programs.html" title="Chapter 29. Multi-threaded programs"> <link rel="prev" href="chapter-multi-threaded-programs.html" title="Chapter 29. Multi-threaded programs"> <link rel="next" href="sec-multithread-example.html" title="Example"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> <div class="navheader"> <table width="100%" summary="Navigation header"> <tr><th colspan="3" align="center">Using Glib::Dispatcher</th></tr> <tr> <td width="20%" align="left"> <a accesskey="p" href="chapter-multi-threaded-programs.html"><img src="icons/prev.png" alt="Prev"></a> </td> <th width="60%" align="center">Chapter 29. Multi-threaded programs</th> <td width="20%" align="right"> <a accesskey="n" href="sec-multithread-example.html"><img src="icons/next.png" alt="Next"></a> </td> </tr> </table> <hr> </div> <div class="sect1"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="sec-using-glib-dispatcher"></a>Using Glib::Dispatcher</h2></div></div></div> <p> The slots connected to <code class="classname">sigc::signal</code> objects execute in the thread which calls <code class="methodname">emit()</code> or <code class="methodname">operator()()</code> on the signal. <code class="classname">Glib::Dispatcher</code> does not behave this way: instead its connected slots execute in the thread in which the <code class="classname">Glib::Dispatcher</code> object was constructed (which must have a glib main loop). If a <code class="classname">Glib::Dispatcher</code> object is constructed in the main GUI thread (which will therefore be the receiver thread), any worker thread can emit on it and have the connected slots safely execute <span class="application">gtkmm</span> functions. </p> <p> Some thread safety rules on the use of <code class="classname">Glib::Dispatcher</code> still apply. As mentioned, a <code class="classname">Glib::Dispatcher</code> object must be constructed in the receiver thread (the thread in whose main loop it will execute its connected slots). By default this is the main program thread, although there is a <code class="classname">Glib::Dispatcher</code> constructor which can take the <code class="classname">Glib::MainContext</code> object of any thread which has a main loop. Only the receiver thread should call <code class="methodname">connect()</code> on the <code class="classname">Glib::Dispatcher</code> object, or manipulate any related <code class="classname">sigc::connection</code> object, unless additional synchronization is employed. However, any worker thread can safely emit on the <code class="classname">Glib::Dispatcher</code> object without any locking once the receiver thread has connected the slots, provided that it is constructed before the worker thread is started (if it is constructed after the thread has started, additional synchronization will normally be required to ensure visibility). </p> <p> Aside from the fact that connected slots always execute in the receiver thread, <code class="classname">Glib::Dispatcher</code> objects are similar to <code class="classname">sigc::signal<void></code> objects. They therefore cannot pass unbound arguments nor return a value. The best way to pass unbound arguments is with a thread-safe (asynchronous) queue. At the time of writing <span class="application">glibmm</span> does not have one, although most people writing multi-threaded code will have one available to them (they are relatively easy to write although there are subtleties in combining thread safety with strong exception safety). </p> <p> A <code class="classname">Glib::Dispatcher</code> object can be emitted on by the receiver thread as well as by a worker thread, although this should be done within reasonable bounds. On unix-like systems <code class="classname">Glib::Dispatcher</code> objects share a single common pipe, which could in theory at least fill up on a very heavily loaded system running a program with a very large number of <code class="classname">Dispatcher</code> objects in use. Were the pipe to fill up before the receiver thread's main loop has had an opportunity to read from it to empty it, and the receiver thread attempt to emit and so write to it when it is in that condition, the receiver thread would block on the write, so deadlocking. Where the receiver thread is to emit, a normal <code class="classname">sigc::signal<void></code> object could of course be used instead. </p> </div> <div class="navfooter"> <hr> <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"> <a accesskey="p" href="chapter-multi-threaded-programs.html"><img src="icons/prev.png" alt="Prev"></a> </td> <td width="20%" align="center"><a accesskey="u" href="chapter-multi-threaded-programs.html"><img src="icons/up.png" alt="Up"></a></td> <td width="40%" align="right"> <a accesskey="n" href="sec-multithread-example.html"><img src="icons/next.png" alt="Next"></a> </td> </tr> <tr> <td width="40%" align="left" valign="top">Chapter 29. Multi-threaded programs </td> <td width="20%" align="center"><a accesskey="h" href="index.html"><img src="icons/home.png" alt="Home"></a></td> <td width="40%" align="right" valign="top"> Example</td> </tr> </table> </div> </body> </html>
