[Development] A QtCore class for event-driven jobs

[Marc Mutz]

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