[Development] Evolving Qt's multithreading API

[Andre Somers]

Op 22-2-2013 11:57, Sze Howe Koh schreef:
>> Some more common use case would be (pseudo-code)
>> >
>> >auto watcher = new QFutureWatcher;
>> >QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff()));
>> >watcher->setFuture(QThrerad::run([]() { return computeStuff(); } ));
>> >// who deletes the watcher?
> If the caller creates the watcher, I think it's fine to let the caller
> delete it too. It's an ordinary C++ practice.
>
Actually, how do you feel about adding an optional _then_ argument to 
the list of arguments of the functions in QtConcurrent and whatever is 
decided to replace the QtConcurrent::run feature? Such a _then_ argument 
could be a slot signature, a function pointer or a lambda function 
(basically, whatever you can use in the Qt 5 QObject::connect). That 
would make it quite a bit easier to work with, I think. It would 
eliminate the need to create (and delete) a QFutureWatcher for a lot of 
cases. The method you passed into the _then_ argument would be called 
when the future is ready. It would be very nice if the _then_ argument 
could optionally have an argument of the return type of QFuture::result.

For this to work, QFuture would not need to be a QObject itself, and 
because you pass in the _then_ argument with the call itself, you don't 
have the race issues that you get if you need to connect in separate 
calls after you have already fired off the thread: no need for 
trampoline objects or the like.

André