[Development] Evolving Qt's multithreading API

[Thiago Macieira]

On segunda-feira, 4 de março de 2013 22.00.34, Andre Somers wrote:
> The point is to get notification when a job is done in the simples way 
> possible. Nothing more, nothing less, without having to check the status 
> of the future.

I understand what you want, but I don't want that. QFutureWatcher serves that 
purpose already. 

> I don't quite get that code at all, by the way. You seem
> to be creating a QFutureWatcher on the stack, and still connecting to
> its deleteLater method?

It was pseudocode. It should have been:
  QFutureWatcher<T> *w = new QFutureWatcher<T>();
  w->setFuture(QThread::start(...));

> I think the proposed API addition is actually quite natural. It is not
> without precedent (QTimer::singleShot()), and would result in quite
> simple, readable code.

I disagree on both accounts. It's not natural: there is no precedent for 
taking two runnables outside of QtConcurrent's own reducing functions (map-
reduce and filter-reduce). In that case, it serves a very specific purpose, in a 
domain where the concept is understood. And besides, that's the very module 
we're trying to replace.

There's also no good API that takes two slots -- the only example I can think 
of is the horrible QDBusConnection::callWithCallback. And that one is made 
simpler and easier by QDBusPendingReply and QDBusPendingCallWatcher, two 
classes inspired by QFuture and QFutureWatcher.

-- 
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/69aacad4/attachment.sig>