[Development] Make a decision for asynchronous APIs

[Elvis Stansvik]

Den lör 1 feb. 2020 kl 14:48 skrev Sona Kurazyan <sona.kurazyan at qt.io>:
>
>
>
> > -----Original Message-----
> > From: Elvis Stansvik <elvstone at gmail.com>
> > Sent: Friday, January 31, 2020 7:20 PM
> > To: Sona Kurazyan <sona.kurazyan at qt.io>
> > Cc: development at qt-project.org
> > Subject: Re: [Development] Make a decision for asynchronous APIs
> >
> > >
> > > Additionally, there are some discussions about QFuture being a mix
> > between a “Task” and a “Future”. One of the options of improving this
> > situation is to make a QTask (or QJob) out of the current QFuture. But then
> > the question is: should we also support a “classic” QFuture? Is there a value
> > in having it, when there are already some very advanced implementations of
> > a future?
> >
> > I don't have too much to comment on this. Would the alternative to QFuture
> > in this scenario be a future class from somewhere else (std::future, ...)? And
> > the Qt goodies like cancel/pause/resume/progress API would be on QTask?
>
> Yes, that would be my preference as well.

Alright, thanks. That sounds reasonable to me too.

Elvis

>
> Best regards,
> Sona