[Development] Evolving Qt's multithreading API

[Sze Howe Koh]

On 22 February 2013 20:06, André Somers <andre at familiesomers.nl> wrote:
> I don't really like the need to create a watcher in order to get a
> signal at all, to be honest. Never did.
>
> My own implementation of a task-based system that I recently did,
> involved returning a QSharedPointer<Task> from the task manager. Task
> derives from QObject, and has signals and slots that can be used
> notification. It is similar to QThread, in that it lives in the thread
> that requested the task. It is inspired on QNetworkAccessManager, that
> immediately gives back an instance of a reply that you can either
> directly connect to or ignore.
>
> Using a shared pointer gave me these advantages:
> * No need for explicit deletes on either side: the requester can hold on
> to the pointer and use it directly, or use a generic signal from the
> task manager object that also contains a shared pointer to the same
> task. When nobody is interested in the task object any more, it is
> automatically deleted.
> * Easily connect to signals like finished() or error() (though it would
> be nice if you could directly connect to a
> QSharedPointer<QObjectDerivedClass> instead of having to use .data() );
> no need for a separate watcher object
> * Value semantics, just like QFuture: a shared pointer is quite cheap to
> pass around
>
> Just like QFuture, it is possible to wait for the task to finish when
> needed.
>
> I'd really like to see such a structure in Qt, as generic as possible.
> Tasks are not only relevant in the context of threads, but also for
> things like network operations and perhaps even I/O operations,
> printing, etc.

There's talk about integrating a 3rd-party task parallelism library
into Qt (although something like TBB offers a lot more than parallel
tasks). If that goes ahead, we should definitely look at incorporating
these structures into the Qt-side wrapper.


Regards,
Sze-Howe