[Development] Evolving Qt's multithreading API

Sze Howe Koh szehowe.koh at gmail.com
Sun Mar 10 17:02:25 CET 2013

On 5 March 2013 23:59, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On terça-feira, 5 de março de 2013 10.11.21, Olivier Goffart wrote:
>> If you do that, there is even a qWarning telling you there will be a race:
>> http://code.woboq.org/qt5/qtbase/src/corelib/thread/qfuturewatcher.cpp.html#
>> _ZN18QFutureWatcherBase13connectNotifyERK11QMetaMethod
>> You should setup the connection before the future.
> Fair enough. You can create the QFutureWatcher before the future. The code is
> even more clear that way.

I've attached 3 draft candidates for the high-level, single-shot
parallel function call API. The chart compares the API itself and use
cases. A subset of QFutureWatcher's API is included for reference.

Preferences and thoughts?

My favourite is the last column, but that requires support for QObject
templates (http://lists.qt-project.org/pipermail/development/2013-March/010286.html)

Things not yet included:
- Ability to specify manual/auto start/delete
- Better support for clean thread cancellation


P.S. It was pointed out earlier that the returned QObject has unclear
ownership. I think that's ok as long as the documentation is clear,
following the example of QNetworkAccessManager::get()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newapi_candidates.png
Type: image/png
Size: 87949 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130311/6a63b420/attachment.png>

More information about the Development mailing list