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

[Denis Shienkov]

Hi Oswald,

> a separate signal would be redundant, as checking byteToWrite() == 0 in
> the slot called from bytesWritten() is sufficient.

Can you, please, more explain of your idea?

BR,
Denis




2014-04-28 13:16 GMT+04:00 Oswald Buddenhagen <oswald.buddenhagen at digia.com>
:

> 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140428/01dd3226/attachment.html>