On Tue, 27 May 2025 at 18:37, Volker Hilsheimer via Development <development@qt-project.org> wrote: > Two thoughts: > > - how does TaskTree fit into a C++26 future with sender/receiver
A quick look based on documentation: 1) it's easy to fit a TaskTree into a sender pipeline, it has signals, so the generic adaptation will just work, and you can slot in the actual start into a pipeline with let_value 2) it would be easy to write a TaskTree sender that produces an operation_state that will start() the tasktree when the operation state is started 3) mapping individual TaskInterface derivatives into senders is similarly straightforward, although there we wouldn't map start() into an operation state start(), because the TaskTree will start() the individual TaskInterface instances 4) TaskTree::progressValueChanged() would be better expressed as a sequence sender, but we don't have those nailed down yet, it's seriously experimental. It can be used in various more-manually-constructed sender pipelines that repeat the connect() to that signal if need be. Including loops that contain a co_await of a sender representing that signal. 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. I don't think there's overlap as such. Sender pipelines and various adaptations there are more generic and more flexible, and less intrusive. Stuff like withLog() and withTimeout() can be non-intrusively added to any pipeline, whereas with TaskTree, they are baked-in functions. The models are vastly, significantly different in how data flows between 'pipeline' elements. In TaskTree, that's done by exchanging data via a Storage. In senders&receivers, you just pass arguments like you would call functions. TaskTree provides some unity and shared understanding of what's exchanged between GroupItems in the same group, senders&receivers allow you to exchange anything. But that also leads to an even bigger difference. Senders & receivers can pass that data by value, moving it between sender pipeline elements. That allows concurrent programming with no mutexes, no atomics, no sharing of anything, and leads into easy concurrent programming that's free of deadlocks and data races. TaskTree doesn't try to solve that problem, and wasn't designed to. That's fine, it had different design goals. But you the user will have to take care of properly synchronized access to the Storage where necessary, as far as I can see. 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. All in all, TaskTree ends up being more specific, and to an extent, more domain-specific. If you want a mechanism that can group your tasks and can facilitate shared storage between them, TaskTree works fine once you do the adaptations for your tasks. It doesn't make the inter-task communication super-easy or less error-prone. It's something we can have right now, and requires no fancy new C++ standard to work. In the long run, Senders & Receivers will take over this sort of functionality, *because* they solve that inter-task communication problem. Once more and more users realize that ability, there will be no return, and no second choices. The various flexibilities and generic adaptation algorithms are nice, but that inter-task communication is the killer feature that will resolve this 'competition'. We might want to investigate ways to pipe the results of tasks in a group to the subsequent ones, without relying on shared storage. That would get TaskTree closer to that killer feature. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
