If the file is on a remote file system, then those functions can also potentially have a high latency.
For example, if you just lost connectivity, then the synchronous function would not complete until it fails with a supervisory timeout at the network layer (e.g. TCP reset in the case of TCP/IP connectivity) > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of ???? ?????????? > Sent: Sunday, September 25, 2011 19:03 > To: [email protected] > Subject: Re: [Qt5-feedback] VFS in qt5 > > Ok, asynchronous data reading is not a problem a well as QIODevice has > asynchronous API. > > But what about other QFile methods? I mean copy, rename, link and > setPermissions. Should they be asynchronous too? > > Next question - what about QVFSDir? Should directory parsing be > asynchronous? > > 25.09.2011, в 21:51, Georg Rudoy написал(а): > > > 2011/9/25 Thiago Macieira <[email protected]>: > >> On Sunday, 25 de September de 2011 01:48:33 Иван Комиссаров wrote: > >>> As long as QFileEngines are marked as deprecated, Qt will have no > >>> possibility to implement virtual filesystem. > >>> > >>> So i would like to discuss features of new VFS. > >>> > >>> I have 2 questions. First - should it work using QFile and QDir > classes as > >>> front-end or it should provide its own API like QVFSFile? Second - > if we > >>> provide new API, should it be synchronous (like QFile) or > asynchronous > >>> (like Q*Socket)? > >> > >> I would prefer a new API, more suited for the task. Whether it is > synchronous > >> or asynchronous, it's up to the implementation. > > > > Personally, I think QIODevice-derived thing would be just enough, > > maybe with additional protocol-specific methods/properties for things > > like FTP mode changes, or such. > > > >> Experience in KDE shows asynchronous is better when a non-negligible > delay is > >> expected. > > > > Agreed. Synchronous QFile-style approach just doesn't scale well to > > operations with remote sources (thus with much greater latencies and > > more faulty ones) and even with local sources that require a lot of > > work to be done (think of accessing a file inside a .xz archive). > > > > After all, it's much easier to make a sync API out of async one given > > all the waitFor*-functions than the reverse. > > > > -- > > Georg Rudoy > > LeechCraft - http://leechcraft.org > _______________________________________________ > Qt5-feedback mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback > > _______________________________________________ > Qt5-feedback mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
