On Monday, 26 de September de 2011 13:09:55 [email protected] wrote: > 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)
Or a timeout in the VFS implementation, depending on the implementation.
I know an asynchronous API is much harder to deal with and leads to more
complex code. Synchronous would make it easier, but you'd have to use a lot
more threading to ensure the UI or other functions aren't blocked. Threading
also has the problem of timeouts.
One of the worst problems with NFS (at least, on Linux with kernel mounts) is
that if the server goes away, the applications hang indefinitely. There's no
soft reset. Usually, the only way to get them back is by making the server
available again or by rebooting.
I'm not saying our VFS layer would have anywhere near those problems. But it
goes to show the kind of failure modes the API needs to handle.
Just like the case of installing generated headers, I have my preconceived
notion that asynchronous is better. But I'd like to keep an open mind -- and
ask everyone else to do to -- and see the benefits of either approach. Whoever
is designing this new addon has the right to make the choices and present
their case for why they chose a particular way.
BTW, if anyone has suggestions on how to write cancellable synchronous code
that is also non-blocking (co-threads?), I'd love to read some more. Vala (the
language) has some concepts in that area, but I don't know how they're
implemented.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
