Review Request 123514: Make it possible to treat non-sequential QIODevice asynchronously

Aleix Pol Gonzalez aleixpol at kde.org
Sun May 3 23:24:11 UTC 2015


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123514/
-----------------------------------------------------------

(Updated May 3, 2015, 11:24 p.m.)


Status
------

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
-------

Submitted with commit b3837c8b3e98393ba56af3f9bddfd46ec64f1098 by Aleix Pol to branch master.


Repository: kio


Description
-------

So far, we used to just read whenever some data was required. This works on sequential devices because the data is already available. This is not the case when we have a sequential device, such as a socket, where data arrives when it arrives. This will also prove useful on non-sequential devices as well when we want to keep reading in case new data appears.

This patch takes the AsyncDataEnabled setting on accordinly by:

* only reading from the device when readyRead is available.
* finishes the transfer whenever the device is closed.


Diffs
-----

  src/core/transferjob.cpp 97a724e 
  src/widgets/accessmanager.cpp b4ec811 
  src/core/job_p.h 7ec1a69 
  src/core/transferjob.h e2fd2e7 
  autotests/jobtest.cpp 327470a 
  autotests/accessmanagertest.cpp 5d52553 
  autotests/jobtest.h 5ccd492 
  autotests/CMakeLists.txt 7bba3ea 

Diff: https://git.reviewboard.kde.org/r/123514/diff/


Testing
-------

Tests still pass, new test also passes.

The test is using lambdas to delay write. I don't think it's available.
Can I add some kind of #if HAS_LAMBDA and make the test depend on it?
I don't think adding slots and make the buffer an attribute would be very nice... I can also sub-class the buffer.


Thanks,

Aleix Pol Gonzalez

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150503/2019813d/attachment.html>


More information about the Kde-frameworks-devel mailing list