Threadweaver or QThread?

Andreas Pakulat apaku at
Fri Sep 28 17:08:35 BST 2007

On 27.09.07 16:34:18, Mirko Boehm wrote:
> 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.

Hmm, there's one doubt: The Threadweaver API docs say that one can't
emit signals directly from a job if those are connected to an object in
a different thread but instead one has to use another object that does
the emitting and to create this object inside the run() method. So if I
create a Job-Subclass I need to do this as well, right?


Tomorrow, you can be anywhere.

More information about the kde-core-devel mailing list