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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
