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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
