[Development] Moving QFuture from QtConcurrent to QtCore
Marc Mutz
marc.mutz at kdab.com
Wed Jul 4 23:09:03 CEST 2012
Hi,
When QtConcurrent was been moved out of QtCore, some of it stayed behind in
QtCore: QThreadPool, but not QFuture. I'm arguing here that QFuture should
stay in QtCore, or else be renamed to QtConcurrent::Future, to not impede
development in that area until Qt 6.
QFuture is currently very much tied to QtConcurrent in that it assumes the
underlying runnable is executing on QThreadPool::globalInstance(), but I've
already submitted a patch some time ago that makes QFutureInterface (the
promise part of QFuture) independent of the QThreadPool instance:
https://codereview.qt-project.org/16942
That change, plus packaging QFutureInterface in a public (and documented :)
QPromise, would go a long way to making QFuture useful for all users of
QThreadPools, not only QtConcurrent ones.
That would be an argument for moving QFuture back to QtCore, alongside
QThreadPool.
If, however, there are mid-term plans to make a Future class in Qt that isn't
tied to QThreadPool (and could thus be used in, say, the I/O subsystem, too),
then I'd argue for keeping QFuture in QtConcurrent and, to free up the name,
call it QtConcurrent::Future (or QtConcurrent::QFuture, but that might be a
bit subtle once a new QFuture appears in QtCore).
Any opinions either way?
Thanks,
Marc
--
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
More information about the Development
mailing list