[Development] Evolving Qt's multithreading API

[Corentin Jabot]

> Yes, very much like that, but updated to also support the Qt5 like way
> of connecting.
>> 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?
> It would not quite, but it would be a bit of a let-down. There still is
> the benefit of not having to worry about race conditions. However, if we
> modify the syntax a little bit, I think we can avoid the additional
> binding step:
>
> QFuture<T> runFunction(QFunction<T> then, QFunction<T> main);
> QFuture<T> runFunction(QFuntion<void> then, QFuntion<T> main);
> QFuture<T> runFunction(QFunction<T> main);
>

I'm gonna sound crazy but...
An important part of the QtConcurrent code do that implicit biding,
and if we were to duplicate those calls for different usages, it's a
lot of boilerplate code.
Also, as said above, it limit the api in the sens that all the require
parameters must be put before
the actual function and its parameters.
Both issues make it harder to maintain and evolve the api.
So, what about let the users make the binding part themselves ?

The syntax could be like
runFunction(QFunction<Foo>::bind(myFunction, arg1, arg2));

assuming the biding part is done using a bunch of functions, it could
be simplified
to

runFunction(qBind(myFunction, arg1, arg2))

instead of the actual

QtConcurrent::run(myFunction, arg1, arg2)


It's arguably less straight forward for the user, but on the other hand,
as we will need extra parameters, putting the options/flags/callback/signals
before the function and its parameter could be even more confusing.

we could then have:
runFunction(QFunction<T> function, Options, callback)



> (Copying your use of QFunction, a quick look at the WIP you mentioned
> doesn't quite reveal to me how it is supposed to work, and I probably
> use it wrong.

QFunction is somehow like std::function, but has support for c++98.
It's actually something between std::function and std::bind ( but does
not support placeholders )

>The then argument could be lambda function, a QObject* and
> a slot signature, a pointer to an object and a member function pointer,
> or perhaps even a plain function pointer. It would be nice if the
> argument for these could be either no argument at all, or of the type T
> so it can just receive the value from the method.)

Agree

>> 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++!
> Yeah, that is a very unfortunate artifact of the way Qt implements
> signals and slots. However, it is what it is...

Would that even be possible ? It sure would be nice

Corentin