On Monday 09 September 2013 14:23:10 Sebastian Kügler wrote: > Martin Grässlin asked if we could offer an async API for this. Opinions?
This task is mostly I/O, and a bit of CPU. Portable async I/O requires doing it in a thread. To avoid setting up a thread every time, this could use QThreadPool (but a dedicated one, to avoid blocking the main one which is supposed to be about pure-CPU operations only), and the runnable would call the sync trader API. So, it's feasible. But is it worth it? 100% of the current code uses the sync API, since it's the only one that exists. So if we don't make it fast, all that code will be too slow. Only newly written code using the async API will be OK. If, instead, we ensure that it's fast enough, then sync call is ok, and the async api is rather useless. The same logic could be applied to everything sync in Qt (QFile, QXml, etc. etc.). They don't provide thread-based async apis around that. Apps that want to move these operations to a thread, can just do that, on top of the sync query(). I tend to think the same applies to locating plugins. All this means is that the trader must work from multiple threads, of course. This is very different from e.g. network operations btw, since the order of magnitude is much bigger for those, and the timing is much less predictable. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel