[Development] Evolving Qt's multithreading API

[Thiago Macieira]

On sexta-feira, 22 de fevereiro de 2013 15.28.44, Corentin Jabot wrote:
> 2013/2/22 André Somers <andre at familiesomers.nl>
> 
> > If only QFuture allowed you to connect... Unfortunately, it is not a
> > QObject
> 
> Oh yeah, I almost forgot that bit. And somehow it looks like the core issue.
> I wonder why by the way:
> 
> We could have something like QObject <- QFutureBase (with all
> requiered signals/slots) <- QFuture<T>
> or is there something I'm not seeing ?
> 
> Of course now its too late, but we could introduce something new, like
> QFutureObject ?

That's QFutureWatcher.

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*.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130222/a984f5ee/attachment.sig>