Hi.
Thank you for yours explanations.
But I had next experience. QImage is implicitly shared too. But I had
following issue:
I had a signal like this
void mySignal( QImage );
and when I tried to use this image in the slot in another thread (queued
connection was used) image was corrupted. Any operation with image
crashed application...
I have to say that image object created in method that emitted
mySignal() on the stack, like this:
void method( const QVideoFrame & frame )
{
QImage image( constructed from frame data );
emit mySignal( image );
}
This issue was solved by copying image like this:
emit mySignal( image.copy( image.rect() ) );
This problem occurs on Windows Surface only ( Qt 5.4.2 ).
What is the problem in this situation?
On 06.10.2015 23:24, Thiago Macieira wrote:
> On Tuesday 06 October 2015 19:43:03 Igor Mironchik wrote:
>> Hi guys,
>>
>> Is it safe to use QString argument in queued slot when signal emitted
>> from another thread?
>>
>> void mySignal( QString arg );
>> void mySlot( QString arg );
> Yes. All arguments passed by value or by const-ref are copied into the event
> that gets posted to the other thread.
>
> And QString, like other Qt value classes, should be treated like an int.
> You're not asking that question about an int argument, so you shouldn't have
> to ask about a QString argument.
>
>> The same question if argument will be const QString & and argument to
>> signal passed as temporary object, like this:
>>
>> void mySignal( const QString & arg );
>>
>> emit mySignal( QLatin1String( "Hello!!!" ) ); // emitted from another
>> thread, different from GUI thread...
>>
>> void mySlot( const QString & arg ); // Live in GUI thread...
> As explained above.
>
--
Best Regards,
Igor Mironchik.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
