On Wednesday 06 August 2014 17:47:49 Milian Wolff wrote: > > > 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. > > Right, then imo just leave it as-is but still add some signals which make it > simpler to use the code as a worker object in a thread. At least, that's my > opinion. Not sure what Kevin has to say in that regard.
My opinion is that the threading shouldn't be forced on the client code. So I would say: signals for the API. If you reuse something third party which doesn't even allow for polling then the thread should probably be in the extractor. In other words: hide the constraints from the third party libraries you are forced to use, don't leak them to your users. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
