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

[Thiago Macieira]

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.

> Of course, the user shall take responsibility for processing in
> Unbuffered mode. But I think that Unbuffered mode isn't necessary. What
> sense in it? What advantages? So, I think, that the Buffered mode it is
> sufficient way. When all data reads from FIFO and stored into internal
> buffer of class, then no exists data loss.

True. We don't offer unbuffered mode for QTcpSocket or QProcess either.

> 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.

>  > PS2 Do you have an internal mailing list for the QSerialPort project?
> 
> No, we don't have it.

Well, yes you do. It's this one :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center