On Wednesday, August 06, 2014 04:09:19 PM Milian Wolff wrote: > > > > Hmm, how would we do async? I thought people could just run it in another > > thread / process if they want. The only thing I can think of changing is > > that the plugins return the result later via a signal instead of doing all > > the work in one function. > > This would be good since it makes it trivial to use it then in a background > Thread - essentially you'd put a worker object into some thread/task which > then emits a signal with the data when its ready. This could be the Manager > (which then automatically finds the correct extractor for the given > mimetype), or a certain Extractor, if you know which one should be used.
It might just be easier to make the manager return a QRunnable with all the extractors for that mimetype ready to run. And then you run them in a thread loop. > > Though note that the above does not mean that a call to extract would be > async. It would still be sync. But you could use QFile and its readyRead > signals internally to process stuff asynchronously and then emit the data > once the end of the file is reached. If the signals are there (see above) > this could be done without changing the API and thus could be done later. With Qt we have QFile and readReady signals so this can be done. But a lot of the extractors use third party libraries which are quite often synchronous. > > > What about the thread safety? At a glance I would say > > > ExtractorPluginManager is not > > This should be investigated. Note that it would be fine to load the plugins > in the ctor (which by definition is never thread safe). Just the usage > later to match a given data set/file against the extractors and to get some > result out of that should be made thread safe. > > Bye -- Vishesh Handa _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
