[Development] QPromise cancellation

[Arno Rehn]

On 28.01.2026 12:37, Ivan Solovev wrote:
>> This becomes interesting when you have nested and/or chained QFutures.
>> Since Qt 6.10 we have QFuture::cancelChain() which propagates the
>> "canceled" flag up a continuation chain (nice!). But we don't yet have a
>> solution for propagating cancelation into nested futures.
> 
> I was trying to solve the "nested futures" problem some time ago
> in scope of https://qt-project.atlassian.net/browse/QTBUG-140786,
> but could not come up with a reasonable solution.
> The discussion in the bugreport has some interesting details.
> I think at some point I came to a conclusion that it is impossible to
> integrate the nested continuations into our internal continuation chain,
> because we simply cannot control when and how they are created.

Thanks for the pointer! I vaguely remember this. Will read up on it.

>> We could use QFutureCallOutInterface directly, but this still feels
>> "dirty". The CallOutInterface was specifically made for QFutureWatcher;
>> continuations disregard it completely. Using QFutureCallOutInterface
>> for this now feels like mixing two systems that were not ever designed
>> to work together.
> 
> I must admit that I did not look at the CallOutInterface when trying to
> solve the problem. So, I'd be interested to have a look at a WIP patch.
> Maybe we could find a way to fit it nicely into the implementation.
> Even though in general I agree that QFuture internals are already
> too complicated.

I'll come up with something, but likely not today anymore. Tracking 
lifetimes across the implicitly shared state is gonna be... "fun".

OTOH, maybe we can unify some of the continuation/CallOutInterface stuff 
while we're at it. Only

>> Looking at how others do it: they don't ingrain cancelation into their
>> promise types at all (JS, C++ stdlib). Instead, if you want something to
>> support cancelation, you explicitly pass down a token of sorts
> 
> BogDan submitted a suggestion that resulted from the previous bugreport.
> See https://qt-project.atlassian.net/browse/QTBUG-141174.
> We cannot unconditionally use std::stop_token now, because we still
> depend on C++17. But maybe exposing QPromise in the continuations
> could be helpful? What do you think?

Yep, that'd work. This is basically what QtConcurrent::run() does: 
https://doc.qt.io/qt-6/qtconcurrentrun.html#concurrent-run-with-promise

Not super ergonomic, though.

Cheers,
Arno

-- 
Arno Rehn
Principal Software Engineer
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.rehn at menlosystems.com
www.menlosystems.com

Menlo Systems GmbH
Bunsenstrasse 5, D-82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324