[Development] Evolving Qt's multithreading API

[André Somers]

Op 4-3-2013 23:56, Thiago Macieira schreef:
> On segunda-feira, 4 de março de 2013 14.49.15, Thiago Macieira wrote:
>>> 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.
> Oh, and if you want simple, one more thing occurred to me:
>
>    runFunction([]() { main(); then(); });
>
> If you need the return value:
>    runFunction([]() { then(main()); });
>
> I will not accept "C++11 isn't available for everyone" as a reason to add a
> more complicated API. The API should be designed for C++11 use and later made
> to work with C++98, with as little modification as possible.
The above doesn't work at all. It will run the then() in the worker 
thread. That is not what you want.

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.

André