[Development] QtCS2024 QFuture/QPromise

[Mårten Nordheim]

> > On 6 Sep 2024, at 22:36, Thiago Macieira <thiago.macieira at intel.com> wrote:
> >
> > On Friday 6 September 2024 16:21:56 CEST Mårten Nordheim via Development
> > wrote:
> >> But do we make it QList<int> _just in case_ there are multiple results
> >> added?
> >
> > From my limited exposure to QFuture/QPromise and in particular the bugs I've
> > had to triage, that is a design flaw.
> >
> > The future/promise doesn't know how many results will be provided, so there's
> > a race condition in it flagging the future has arrived with more results
> > arriving.
>
> QFuture is QGenerator in disguise.

I suppose that's more accurate, but if we are going to treat it it as a generator
then it shouldn't be co_awaited, generators are just iterated across until they're
exhausted.

We could in theory both provide co_yield and overload `operator co_await`  to try to
handle co_awaiting it, but IMO then we should just wait until it is finished, not just until
the next result is ready. What should happen in this scenario:

auto r = co_await future;
// result 1 and 2 are ready; r = 1?
co_await future;
// result 3 is ready; r = 3?

If we instead wait for the whole future to finish we avoid this. The iterated approach would
also avoid it. Though that brings us back to earlier - if we QFuture is both a generator and a
single-return-value task type, are we forced to always return a list of results for a co_await?

> Can we make it std::optional<T>? co_await awaits the next result, which might turn out to
> be "no result” (we don’t know at the time of the co_await call). Would that work?
> 
> Even in the case of a single result only that can still be “no result” in case of
> cancellation, which again would suggest using an optional.

Yeah, I was thinking of this, though just an optional isn't the best.
We should have something like std::expected<T, Err> so we can return something
like "UserCancelledOperation", instead of just not having a value to give back.

> Morten

Mårten

--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development