[Development] Making TaskTree a public API

[Jaroslaw Kobus]

Confidential
> ________________________________________
> From: Ville Voutilainen <ville.voutilainen at gmail.com>
> Sent: Tuesday, May 27, 2025 11:28 PM
> To: Volker Hilsheimer
> Cc: Jaroslaw Kobus; development at qt-project.org
> Subject: Re: [Development] Making TaskTree a public API

[...]

> An observation:
>
> TaskTree and especially the Tasks it runs and adapters thereof are
> inheritance-based, senders&receivers don't require that at all. But
> that's neither here nor there.
> Some people like the one flavor, other people like the other. A fairly
> objective difference is, though, that it takes a bit more work to
> adapt a custom task
> into the TaskTree model, due to having to write adapters using inheritance.

As of PS 49 https://codereview.qt-project.org/c/qt/qttasktree/+/661219/49
the polymorphism is gone from task adapters, see the diff:
https://codereview.qt-project.org/c/qt/qttasktree/+/661219/47..49

Now the TaskTree framework is free from any virtual method.

[...]

> It seems far less straightforward in the TaskTree model to take a
> bunch of task functions and run them in whichever execution context,
> i.e. bounce them
> between different threads. That's easy as pie in the senders & receivers model.

That's actually possible - you may use For loop in parallel mode with QConcurrentCallTasks, like:

const LoopList iterator(...); // pass some QList<...> here

const Group recipe {
    For (iterator) >> Do {
        parallelLimit(parallelIdealThreadCountLimit),
        QConcurrentCallTask(...)
    }
};

In this case we will run in parallel tasks executed in separate threads
(max. parallelIdealThreadCountLimit tasks running at the same time)
for each element of the list passed to the iterator.

Best regads

Jarek