Confidential > ________________________________________ > From: Ville Voutilainen <ville.voutilai...@gmail.com> > Sent: Tuesday, May 27, 2025 11:28 PM > To: Volker Hilsheimer > Cc: Jaroslaw Kobus; development@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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
