> ________________________________________ > From: Volker Hilsheimer <volker.hilshei...@qt.io> > Sent: Tuesday, May 27, 2025 5:35 PM > To: Jaroslaw Kobus > Cc: development@qt-project.org > Subject: Re: [Development] Making TaskTree a public API > > Hi Jarek, > > > Thanks for pushing this forward, after several discussions at Qt Contributors > Summits over the past years. For reference: > > - 2023: https://wiki.qt.io/TaskTree_CS23 > - 2024: https://wiki.qt.io/QtCS2024_TaskTree > > > Two thoughts: > > - how does TaskTree fit into a C++26 future with sender/receiver
That is not easy for me to compare, because I don't know the details of sender/receiver lib. However, we have some separate examples of the TaskTree usages here (the code is independent on any Creator internals): https://github.com/qt-creator/qt-creator/tree/master/tests/manual/tasking/imagescaling https://github.com/qt-creator/qt-creator/tree/master/tests/manual/tasking/trafficlight https://github.com/qt-creator/qt-creator/tree/master/tests/manual/tasking/dataexchange and we have an usage in assetdownloader. So, having these examples (and assetdownloader) implemented in terms of Execution Control Library would help in comparing both solutions, in terms of code readability and in terms of how well they integrate with Qt itself. > > - what’s the advantage of having TaskTree/QtTasking in qtbase, vs a dedicated > repository The TaskTree itself (without adapters) is only dependent on QtCore, and it's fine to place it in qtbase or outside. The problematic thing are adapters, which depend on various other modules, like the adapters for: QProcess QNetworkReply QtConcurrent and so on. It's easy to imagine, that some new module may appear in the future, that provides some asynchronous API that would be worth to write an adapter for it in terms of TaskTree. A possible candidate may be e.g. qthttpserver module, that exposes some async APIs. So, I'm fine to place the TaskTree in a separate repository, provided that we have a clear plan on how to integrate adapters (and future adapters) without struggling with the possible dependency issues. Jarek > > These two are somewhat related: if TaskTree and sender/receiver overlap, and > the former is to some degree made obsolete by the latter, then having it in > qtbase might not be optimal. > > But even if they don’t: should we increase the amount of stuff that lives in > qtbase? qtbase is a necessary artefact due to the entanglement of certain > modules; we don’t have it by design (various opinions about mono-repo aside). > Adding more modules to it seems suboptimal, unless we plan to use QtTasking > within any of the existing qtbase modules (in which case it would be good to > know what the plans are to do so). Getting changes into qtbase is … no joy. > > The asset-downloader using it might be one reason, but then looking at how we > are using that right now, perhaps it was suboptimal to add that one to > qtbase; the only example that uses that (short of the example showing how to > use the downloader, which is in qtdeclarative…) is the car-configurator, > which is in qtdoc. So if there is no other good reason to have QtTasking in > qtbase, then it might be more sensible to move the asset downloader helper > into qtdoc. Examples that come with such large assets that we need to > download them explicitly would then have to live in qtdoc as well - which is > perhaps ok. > > > Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
