>Just as with current API for sockets, for example, using the waitFor* family >of functions.
This isn't a good example - sockets can only do that because they can do something special with the socket descriptor internally. (a blocking select() call) In general, it's better to know whether the request is asynchronous or synchronous before starting it. That gives more flexibility to the implementation. A waitFor function in the general case requires a nested event loop. I'd suggest a parallel API for synchronous usage. e.g. write(data) - emits bytesWritten() when done writeSynchronous(data, timeout) - blocks until the write completed or timeout occurs. Or to do it at the class level: QSyncVFSDirIterator - sync implementation, functions take timeout parameters and block until done QAsyncVFSDirIterator - async implementation, functions emit signals when done The synchronous implementation can be done by running the asynchronous version in a worker thread. Or where the underlying API has synchronous and asynchronous versions, it can use the synchronous version. ________________________________ 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
