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

Oswald Buddenhagen oswald.buddenhagen at digia.com
Mon Apr 28 11:16:27 CEST 2014


On Sun, Apr 27, 2014 at 01:34:52PM -0700, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 11:08:44, Denis Shienkov escreveu:
> > Here I am a little disagree. Because in Unbuffered mode, loss of data is
> > exists. For example, in a case when the port accepts a data stream. And
> > when the user ignores readyRead() signal, i.e do not reads nothing from
> > port. In this case FIFO of device/driver will be overflowed, that will
> > cause overrun/overflow errors, and part of stream will be lost.
> 
> Doesn't happen with pipes, sockets and other devices with flow control.
> 
yeah, but serial ports can be operated without flow control. if the
kernel does not buffer indefinitely (which seems plausible, as otherwise
one could DoS it), data could be discarded indeed.

> > As I wrote above, the only Windows has an "true" async I/O. The Unix has
> > not this feature, he has only "non-blocking" approach, but it is not an
> > "async" I/O. So, implementation of completion of I/O operation is
> > problematic on any Unix's.  We only can judge about operation completion
> > indirectly, e.g. for writing - wait for the Tx-empty event.
> 
> By the way, what is that tx-empty event? Note that sockets and pipes don't 
> have that, so please don't make QSerialPort use that by default. You can add 
> an extra signal to QSerialPort to indicate this, but bytesWritten() must mean 
> the same as QTcpSocket and QProcess.
> 
a separate signal would be redundant, as checking byteToWrite() == 0 in
the slot called from bytesWritten() is sufficient.




More information about the Development mailing list