[Development] Evolving Qt's multithreading API

[Sze Howe Koh]

On 2 March 2013 18:17, Andre Somers <andre at familiesomers.nl> wrote:
> 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.

Do you mean like the last argument to QTimer::singleShot()? (this
needs to be updated to support Qt 5 slots, by the way)

Yes, that could work. To make it truly optional though, the main
parallel function would have to be pre-bound by the programmer (e.g.
using https://codereview.qt-project.org/#change,45294), since the
argument list is variable-size.

    QFuture<T> runFunction(QFunction<T> main, QFunction<S> then = NullFunction);

Would the extra binding step nullify the convenience of not requiring
a signalling object?


Or, what if the run-function returns a QFutureWatcher which already
has a QFuture attached -- would that ease the burden from the
programmer a bit?

It's such a shame that template classes can't be meta-objects...
otherwise we could emit the return value directly. That would truly be
event-driven C++!


Regards,
Sze-Howe