mirror of https://github.com/qt/qtbase.git
65b7217ae7
For now, as a private API.
The QRandomAccessAsyncFile class is supposed to handle async read
and write operations. Note that some operations (e.g. open() and
size()) are synchronous, because the tests showed that they
normally would not block even if the file is not actually downloaded
(e.g. stored on a MS OneDrive).
The implementation for async calls is inspired by QNetworkAccessManager
and QNetworkReply. The request for an async read or write returns a
pointer to a QIOOperation object. That object will emit a finished()
signal when the operation is complete, and an errorOccurred() signal,
if there was any error. The user has to connect to these signals to
handle the results. The typical usecase would be:
QRandomAccessAsyncFile file;
file.open(path, mode);
auto op = file.read(offset, maxSize);
connect(op, &QIOOperation::finished, &file, [op] {
if (op->error() != QIOOperation::Error::None)
// handle error
// handle the data
op->deleteLater();
});
Similarly to QNetworkReply, the user has to call deleteLater() in the
callback that is connected to the signal.
The API provides two types of methods:
* owning methods that take ownership of the provided data-to-write or
read into a buffer that is allocated internally. These are
QRAAF::read() and QRAAF::write(). They exist for simplicity and user
convenience.
* non-owning methods that rely on the user to keep the provided buffers
alive as long as the operation in not completed. These are
QRAAF::readInto() and QRAAF::writeFrom(). They have overloads taking
span-of-spans, which should allow to implement vectored IO.
QIOOperation should become a public class at some point.
This means that its APIs should be easy to use, and also extensible.
It should not be limited to only Read and Write.
The hierarchy of IO operations is represented by QIOOperation and its
derived classes. The base class can be used when the user is not
interested in the data of the operation, or if the operation should
only report success of failure.
The derived classes implement data() methods with various return
types. The classes that represent Read and Write operations also
additionally provide offset() and numBytesProcessed() methods.
The patch also introduces QtPrivate::QIOOperationDataStorage that
holds a std::variant of all possible values that the operation can
contain. If needed, this variant can be extended to hold a QVariant
in order to store an arbitrary value.
This patch also provides the fallback QThreadpool-based implementation
that simply executes the requests on the dedicated threadpool using
QFuture. For simplicity, this implementation uses QFSFileEngine to
provide all operations.
The implementations for various backends should be added in follow-up
patches.
Task-number: QTBUG-136763
Change-Id: I8f34f9e78d91aa35756352de7fbe6544b58de23e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
||
|---|---|---|
| .. | ||
| auto | ||
| baseline | ||
| benchmarks | ||
| global | ||
| libfuzzer | ||
| manual | ||
| shared | ||
| testserver | ||
| CMakeLists.txt | ||
| README | ||
README
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.