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