[Development] Evolving Qt's multithreading API

[Sze Howe Koh]

On 23 February 2013 00:11, Thiago Macieira <thiago.macieira at 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