<div dir="ltr"><div>That said, it's equally possible I am wrong and SignalIdle technically is not thread-safe. I can't really make sense of the wording in the docs...</div><div><br></div><div>for connect_once(), we have:</div><div><br></div><div>> Because <a class="elRef" href="http://library.gnome.org/devel/libsigc++/unstable/structsigc_1_1trackable.html">sigc::trackable</a> is not thread-safe, if the slot represents a non-static method of a class deriving from <a class="elRef" href="http://library.gnome.org/devel/libsigc++/unstable/structsigc_1_1trackable.html">sigc::trackable</a>, and the slot is created by <a class="elRef" href="http://library.gnome.org/devel/libsigc++/unstable/group__mem__fun.html#gadf6b6d22c503b439019f0a2e77352419">sigc::mem_fun()</a>, <a class="el" href="https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalIdle.html#a94217dc63e35f96b5cee4c48f2cdd020" title="Connects an idle handler that runs only once.">connect_once()</a> should only be called from the thread where the <a class="el" href="https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalIdle.html">SignalIdle</a> object's <a class="el" href="https://developer.gnome.org/glibmm/stable/classGlib_1_1MainContext.html" title="Main context.">MainContext</a> runs. You can use, say, boost::bind() or, in C++11, <a class="elRef" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01513.html#ga7b2eddb726568256e49824ad01a05099">std::bind()</a> or a C++11 lambda expression instead of <a class="elRef" href="http://library.gnome.org/devel/libsigc++/unstable/group__mem__fun.html#gadf6b6d22c503b439019f0a2e77352419">sigc::mem_fun()</a>.</div><div><br></div><div>That makes enough sense and still leaves plenty cases for which it'll definitely be safe.</div><div><br></div><div>but for connect(), we have the unconditional:<br></div><div><br></div><div>> This method is not thread-safe. You should call it, or manipulate the returned <a class="elRef" href="http://library.gnome.org/devel/libsigc++/unstable/structsigc_1_1connection.html">sigc::connection</a> object, only from the thread where the <a class="el" href="https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalIdle.html">SignalIdle</a> object's <a class="el" href="https://developer.gnome.org/glibmm/stable/classGlib_1_1MainContext.html" title="Main context.">MainContext</a> runs.</div><div><br></div><div>I would expect the same condition(s) to apply to connect() as to connect_once() - since AFAIK, all the once version does is just disconnect itself automatically - but I might just be missing some obvious reason why this can't be the case. And now I feel like maybe I've had this discussion in the past...!<br></div><div><br></div><div>Anyway, I mentioned it because I have had the usual crashy behaviour symbolic of trying to access widgets in threads other than the main one, in my own projects, and wrapping the code doing said accesses in a lambda run in SignalIdle has always fixed it. Maybe I've just been lucky so far?</div><div><br></div><div>Thoughts/corrections to me from those more experienced at doing multi-threading with gtkmm are welcome.<br></div></div>