[Development] Evolving Qt's multithreading API

[Sze Howe Koh]

On 22 February 2013 21:31, Corentin Jabot <corentin.jabot at gmail.com> wrote:
> Here again, two different issues.
> 1/ can we use the c++11 <functional> features and variadic templates
> for the biding part.
> 2/ should we use the c++11 thread api somehow ( that looks like a huge
> - unnecessary ? - change )

I don't think there's a need to change Qt's underlying threading
system (yet?). Pthreads and  Win32 threads do the job fine.

<snip>

> I was actually wondering if QtConcurrent couldn't be upgraded/recycled
>     * adding QtConcurrent::runFunctionInNewThread(function, ...)
>     * adding QtConcurrent::runFunctionInThreadPool(QThreadPool* p,
> function, ... )
>     * adding QtConcurrent::runFunctionInGlobalThreadPoool(function, ...);
>     * deprecating QtConcurrent::run and make it an alias of
> QtConcurrent::runInGlobalThreadPoool

We decided to halt development of QtConcurrent, and only keep it for
compatibility purposes (see comments in
https://codereview.qt-project.org/#change,39375)

How do you propose we run QRunnable in a non-threadpool thread?


> This way, QThread keeps its current purpose of exclusively handling thread.
>
> (Or we could add another class or namespace, like QAsynchronous,
> reusing QtConcurrent would meant keeping c++03 compat and its suppose
> we will still return QFuture)

Or a low-level QtGlobal function? qAsyncRun(func, args...)


> About returning QThread* : what about the function return value ? That
> should be accessible, easily.
> It's one of the reason I prefer QFuture over QThread*

Yes, that's the weakness of QThread*. We have some mutually exclusive
features at the moment; we'll have to decide which one we want more:
- Easy signalling (QThread)
- Ability to postpone start (QThread)
- Easy return value retrieval (QFuture)


Regards,
Sze-Howe