Re: Invoking GTK main thread from other threads

[Daniel Boles <dboles src gmail com>]

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...

for connect_once(), we have:

> Because sigc::trackable is not thread-safe, if the slot represents a non-static method of a class deriving from sigc::trackable, and the slot is created by sigc::mem_fun(), connect_once() should only be called from the thread where the SignalIdle object's MainContext runs. You can use, say, boost::bind() or, in C++11, std::bind() or a C++11 lambda _expression_ instead of sigc::mem_fun().

That makes enough sense and still leaves plenty cases for which it'll definitely be safe.

but for connect(), we have the unconditional:

> This method is not thread-safe. You should call it, or manipulate the returned sigc::connection object, only from the thread where the SignalIdle object's MainContext runs.

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...!

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?

Thoughts/corrections to me from those more experienced at doing multi-threading with gtkmm are welcome.