[Development] A QtCore class for event-driven jobs
Marc Mutz
marc.mutz at kdab.com
Fri Sep 13 22:30:27 CEST 2013
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
More information about the Development
mailing list