| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tricky case now would be to handle the case when the user tries
to call open() several times. Make sure that after the first operation
is started, all the subsequent attempts to open will fail until the
first operation is finished. Obviously, if the first open() was
successful, the file needs to be closed before it can be re-opened.
Add unit-tests to cover these cases.
Also add some tests for close() corner cases. These tests are useful
for this commit, as the logic of opening the file got more complicated.
Task-number: QTBUG-136763
Change-Id: Id505e6278fbc1d523a52b54e69ba896a3d754762
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add tests that check read/write operations with empty buffers.
For owning read also test a case when a negative maxSize is provided.
The latter revealed that the code was not handling negative maxSize
properly. So, add a warning and reset it to zero in such case.
The value of zero does not have any special meaning, and would simply
result into the operation emitting finished() immediately.
Task-number: QTBUG-136763
Change-Id: I72232a788ce2a18188f76d50db00b09b1af57169
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The flush() operation would normally return bool, indicating if it was
successful or not. As a result, we can use a base QIOOperation to
represent the async call, and just check its error code.
The new tests are designed with the assumption that flush() would act
as a barrier operation, making sure that all read/write operations
before it will finish.
Task-number: QTBUG-136763
Change-Id: I4119eb3218da1985a63fe808da7be754caf4e9d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
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>
|
