[Development] Evolving Qt's multithreading API
thiago.macieira at intel.com
Tue Mar 5 08:56:35 CET 2013
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);
> connect(watcher, SIGNAL(finished(), this,
> 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
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...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development