[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:
>> 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
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...
Size: 87949 bytes
Desc: not available
More information about the Development