[Development] Evolving Qt's multithreading API

[Thiago Macieira]

On terça-feira, 5 de março de 2013 08.54.35, André Somers wrote:
> Op 5-3-2013 8:41, Thiago Macieira schreef:
> > On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote:
> >> I'd appreciate a reply on the point that when using a QFutureWatcher,
> >> you don't know if the future is already done or not at the moment you
> >> connect.
> > 
> > It's not done, by construction.
> 
> So, if I understand you correctly, the following is completely safe right?
> 
> QFuture<void> future = QtConcurrent::run(someFunction, 42, "blah");
> //... perhaps some code, but not returning to the event loop
> QFutureWatcher* watcher = new QFutureWatcher(this);
> watcher.setFuture(future);
> connect(watcher, SIGNAL(finished(), this,
> SLOT(resultOfSomeFunctionReady()));

Yes.

> So, when _does_ the work start for the future then? 

Immediately. In fact, the future might be finished before run() returns. 
However, it's not notified.

> Because all the
> documentation for QtConcurrent suggests that the work is started
> immediately if there is a free thread in the pool. And if the work can
> indeed start immediately, how is is guaranteed that at the moment you
> create your watcher your future is not done yet?

By construction. The code was designed so that if you do that, it will still 
emit finished().

I explained how to achieve this in another email in this thread.

-- 
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/20130304/439cebfa/attachment.sig>