[Development] [QIODevice]How to correctly treat/understand of the documentation?

Denis Shienkov denis.shienkov at gmail.com
Fri May 23 11:28:47 CEST 2014


hi, everybody,

Again  I want to continue discussion of previous thread:
http://lists.qt-project.org/pipermail/development/2014-April/016780.html

I will remind that earlier I made an summary of the general moments of
behavior at I/O implementation that should be in ideally (yes?):

1) Buffered mode

- reading and writing is carried out via the internal buffer of class
- data transmission should be "postponed" and is carried out only on events
from a notifier (when the FIFO of driver/device is ready for I/O
operation).  Similar with the current buffered QTcpSocket implementation...
- bytesWritten() signal has to be emitted after an data transmission from
the user space to kernel space (i.e. after a successful write(),
WriteFile() syscall's). Similar with the any Unix implementation of
QTcpSocket, QProcess...
- data reading is carried out automatically when FIFO is ready for reading
(by event from the read notifier). A data from the FIFO will be read into a
internal read buffer of class. Similar with the current buffered QTcpSocket
implementation...
- the readyRead() signal should be emitted after successfully automatically
reading from the FIFO into internal buffer of class.

2) Unbuffered mode

- reading and writing is carried out directly to the device, by avoiding of
the internal buffer of class
- data transmission should be "directly" by means of calling the ::write(),
::WriteFile() syscalls.  Similar with the current unbuffered QTcpSocket
implementation...
- bytesWritten() signal has to be emitted after an data transmission from
the user space to kernel space (i.e. after a successful write(),
WriteFile() syscall's). Similar with the any Unix implementation of
QTcpSocket, QProcess...
- data reading is carried out manually by user, when the FIFO is ready for
reading (by the readyRead() signal or something else), by means of calling
of the ::read(), ::ReadFile() syscalls. Similar with the current unbuffered
QTcpSocket implementation...
- the readyRead() signal should be emitted when the FIFO is ready to read.


But, I am confused by behavior of a bytesWtitten() signal in the buffered
mode at such approach.
It turns out that then the waitForBytesWritten(msec) method doesn't make
sense since all operations of writing on a descriptor are non-blocking, and
will be are carried out instantly.

e.g. this no make sense:

dev.write();
dev.waitForBytesWritten(1000);

because waitForBytesWritten() returns immediately!

Thus, I suggest to emit the bytesWritten() signal only when corresponding
(non-blocking or asynchronous) operation of writing on a descriptor is
really complete.

e.g. on Unix for this purpose is enough to catch the signal activate()
from the QSocketNotifier (in Write mode of QSocketNotifier). This signal
means that the last portion of data was successfully write (i.e. in fact,
this certain similarity, emulation of asynchronous operations). where
system call ::write() is similar to startAsyncWrite(), and on a signal
activate() from SocketNotifier we have to do completeAsyncWrite(). Where,
from completeAsyncWrite() we have to emit the bytesWritten() signal, but
not in startAsyncWrite()! I think that it is an important difference!

e.g. on Windows for this purpose is enough to catch the signal activate()
from the QWinEventNotifier (or QWinOverlappedEventNotifier).. Where the
signal activate() means that asynchronous overlapped operation is complete
(i.e. previous portion of data was write), and, only after this we can emit
an signal bytesWritten(). Of course, on Windows this can be easy to
implement, because Windows supports an asynchronous I/O operations by
design (against to Unix, which supports only non-blocking I/O (I do not
talk asynchronous about an aio_read/aio_write syscalls, because this is not
used in Qt core)).

Thus, if to follow the principles which I offered, everything becomes clear
and transparent. And I would prefer such option because it is simple to
implement and reflects reality.

PS: I up this subject in a context of QtSerialPort module where it is
unacceptable to take as a basis the current I/O approach from the
QAbstractSocket, etc. I do not like a current approach inside of QtCore..

BR,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140523/050903bd/attachment.html>


More information about the Development mailing list