Quote Originally Posted by Ambiorix
Hello,
Hi

Qt4 claims to have a thread safe way of emitting signals between threads. Many of Qt4's slots have Qt4 data types in their signature. The copy constructors of these types are reentrant but not thread safe. However this problem is avoided since most of the time const references are used as slot arguments e.g. void mySlot(QString const& arg). That means that the slot gets the address of the data but cannot modify these data. Okay! But what about the thread that emitted the signal. I see trouble when in the emitting thread the QString goes out of scope or is modified before the slot dealt with the QString.
No, that's not true. Queued connections perform a serialisation and deserialisation of objects passed as signal arguments, so it doesn't matter if the object goes out of scope before the slot is executed or not. You can see that if you create some custom object and try to use it as a signal argument or if you try to use a non-const reference to some object. Result:
"QObject::connect: Cannot queue arguments of type 'QString&'"

What stunned me was that my program nevertheless crashed when I used in the emitting thread a const QString that did not went out of scope!! When I wrote similar code for a slot with an integer argument the program did not crash. My conclusions: 1. Qt4 is doing something dirty when queing a signal to the receivers event loop. 2. Qt4's signal/slot mechanism across threads is NOT THREAD SAFE.
My conclusion:
1. Your conclusions seem not to be reliably confirmed, as your test program runs all the time while I am writing this post and it didn't crash. BTW. You had a spelling error in one of the connect statements... Maybe that was the problem?

I include my code which I have build using the Visual Studio .NET 2003 compiler on a Windows XP-system.
I tested it under Linux/GCC4 and it runs fine.

Ok, I am killing the app now and trying some other version of "crashing" run()... Seems to work flawlessly...