On 23 February 2013 00:11, Thiago Macieira <thiago.macie...@intel.com> wrote: > The fact is that any QObject that is returned from those functions -- if any > -- must belong to the calling thread. That implies the necessary guarantees in > terms of signal emissions. > > For example, if the functions return a QObject pointer, a signal-signal > connection from the actual target object's finished() signal to the returned > object's finished() will apply the necessary queueing semantics. > > That also speaks against returning a QThread*.
I haven't understood your point, sorry. Can you please clarify what "necessary guarantees" you were referring to, and how this "speaks against returning a QThread*"? I thought QThread and QFutureWatcher were designed to signal the status of the new thread while living in the original thread. I also couldn't find a need to link up 2 finished() signals -- QThread will emit finished() when QThread::run() returns, and QFutureWatcher emits finished() in response to a callout event, not another signal. Regards, Sze-Howe _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
