[Development] A QtCore class for event-driven jobs

[Peter Kümmel]

On 10.09.2013 08:16, Knoll Lars wrote:
>
> Develop it in a playground project, show why it makes sense and once you have a stable API let's discuss into which module it should go.

An idea I already had when I saw the QUniquePoiner implementation:

Couldn't we add a new branch to dev/stable/release, which is open for very experimental code?
Creating a playground project just for one class is too complicated, and most people would not give them a try,
but only switching a branch lowers the barrier a lot.

We could base the branch on stable, so it is a good starting point for experiments, and
it would be easy to try out these new features without the hassle of checking out (multiple) other repositories,
or by cherry-picking stuff.

Peter

>
> Cheers,
> Lars
>
> From: Konstantin Ritt <ritt.ks at gmail.com <mailto:ritt.ks at gmail.com>>
> Date: tirsdag 10. september 2013 00:40
> To: "development at qt-project.org <mailto:development at qt-project.org>" <development at qt-project.org <mailto:development at qt-project.org>>
> Subject: Re: [Development] A QtCore class for event-driven jobs
>
>
> 2013/9/9 Sune Vuorela <nospam at vuorela.dk <mailto:nospam at vuorela.dk>>
>
>     The api has been stabilized and well tested since like forever.
>
>     Let's get a QAbstractJob heavily inspired by KJob in now.
>
>     A nice side effect of getting it in now is that the myriad of nice
>     frameworks KDE is preparing for ship could be built on QAbstractJob and
>     KDE could skip shipping KJob and move everything over to QAbstractJob
>     now and not after we in KDE has made our first release where we promise
>     to keep ABI and API stability.
>
>
> That's indeed what I was afraid of. Your goal is KJob in Qt 5.2 so you can use it by only linking to QtCore.
> Once released, it's API become frozen up until 6.0...and you don't really care about all others who may disagree with it's design or simply can not use it due to it's limited API and so on.
> All I've seen so far (following by David's links) is a piece of KIO where some API is still hardcoded to be used by KIO. I'd say this is not a 5.2 material at all.
>
> Let us see those nice QProcessJob and/or QThreadJob, that QDBusCallJob...or usable drafts at very least.
> Until then, I'm all in doubts about how useful would that be to the user.
> In example, David said job's doStart() enqueues the runnable in the thread pool; now looking at the code - it seems like we could have then "started()" signal emitted, say, 5 seconds earlier than the runnable gets dequeued and executed. So `for (int i = 0; i < 100; ++i) (job = someoperation(params))->start();` gives us 100
> "started" jobs where only few of them got dequeued and really started; and thus all other jobs can not report their actual execution state change because they were "started" and become "started", once dequeued by worker thread...weird, isn't it?
>
> First of all, put the initial implementation to Qt-project as a module.
> Let's then gather such a use-cases and see where the current API is not sufficient, then polish the API to make QJob usable in all those cases; let's write some QJob-s based demonstration framework and polish the API once again, if needed... and only then we'll see if it is good enough for QtCore.
>
> Kind regards,
> Konstantin
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>