Threadweaver or QThread?

[Mirko Boehm]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Pakulat wrote:
...

>> * have the slot in the main widget show the dialog, then set the result
>> on the job. the method that sets the result can wake the wait condition
>> at the end.
> 
> Ok, I'll do it with events instead of signals/slots because I have to
> transport some data from the worker thread to the GUI thread (yes I
> could do that as well via the signals, but I find it easier this way)
Now this reply worries me - using events is rather old-fashioned and
rough. If you want to transport data - send a pointer to the job object,
and add methods to retrieve the job objects properties (remember, the
driving thread is in a wait condition, so you already took care of
synchronization). And the pointer can easily be a slot argument. No need
for a event class, et cetera.

> 
>> If you have to perform such operations in many different ways, I suggest
>> a command pattern implementation.
>>
>> The described approach works both from within a ThreadWeaver job (which
>> is a QObject), and from within a QThread::run method. Make sure to
>> explicitly create the connection asynchronously, or to otherwise be
>> sure the slot is not called from the second thread.
> 
> Thats mainly what I wanted to know :) Wasn't sure if I can treat a
> threadweaver job like a plain QThread in this regard.
It is not the same thing - a Job is a QObject, but not a QThread.

Cheers,
Mirko.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+79qYSSaITCTnKURAn1CAJ9hX310Fkbr4JApNMeRqI3OnDkkTwCeK/Ae
Jk4tatA615lRpEexJWoDY0c=
=RbND
-----END PGP SIGNATURE-----