[Development] A QtCore class for event-driven jobs

[Konstantin Ritt]

Thanks Marc,

that's exactly what I was saying about. The only difference is (seems to
be) a user-visible "manager" that "owns" (or let's say "locks") the task up
until it gets processed so no deletion may occur in the middle of
execution, i.e.
What the manager is and where/how it executes the tasks is probably up to
the user but having a "standard" interface with some guaranteed
functionality is for good, IMO.

Regards,
Konstantin


2013/9/13 Marc Mutz <marc.mutz at kdab.com>

> On 2013-09-12 08:07, André Somers wrote:
> > Op 11-9-2013 17:19, David Faure schreef:
> >>> Couldn't such a class be part of the hopefully coming QtConcurrent
> >>> replacement?
> >> Can we forget about threads for a second?
> > No, I'd rather not forget that huge pink elephant in the room... In
> > this
> > age of multi-core systems being the norm rather than exception, we
> > simply cannot ignore threads when designing a generic API for
> > asynchronous jobs.
> >>
> >> The main point of event-driven jobs is to have them use the event
> >> loop, NOT
> >> threads.
> > That sounds pointless to me. Why would you design an API for
> > asynchronous jobs, but limit that to those jobs that use the eventloop?
> > What does the user of the API really care what the API does to pull of
> > the async-ness? Compare with QNAM: it uses threading too in the
> > background, doesn't it?
> >
> > To me, a generic job API only makes sense if the API makes sense for
> > all
> > async operations, no matter if the job itself uses threading or the
> > eventloop to work. Both should work equally well, and have equal
> > support
> > IMHO.
>
> Seconded.
>
> I, too, have written Job-classes, but I wouldn't do so anymore. That
> concept is so 90's.
>
> I'd use a future. A future isn't (necessarily) the result of a thread.
> It's a placeholder for an asynchronously calculated result. That could
> be a UDP message. And Qt's future can even transport progress, and
> supports cancellation and stop/resume. It's not a QObject, except if you
> want it to (QFutureWatcher). All that's needed is to wrap
> QFutureInterface into a QPromise (and wrap that one into a
> QPackagedTask). And the future needs .then() support.
>
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130914/9cd26e9e/attachment.html>