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

[Denis Shienkov]

Hi Thiago,

> By the way, what is that tx-empty event?

E.g., it is an signal of QSocketNotifier::activated(fd) for the Write type
of notifier.

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

No, it not so. This statement isn't correct even for existing classes from
Qt-core, Qt-network (see below):

For example, all classes using of the QPipeWriter (QProcess??,
QLocalSocket) in Windows implement an "true" bytesWritten() signal. When
the bytesWritten() is emitted after each I/O completion (at least, it got
an numbers of transferred bytes after each completion and accumulate it).
But on other platforms (on *nix) it isn't implemented by a similar method
(since in principle there is no asynchronous I/O in *nix). Therefore there
bytesWritten() signal is emitted without "waiting" for the fact of real
sending of data. Thus, the same QProcess or QLocalSocket will behave
differently on different platforms (I told it already in previous mails).

So, what behavior should I take as "basic" for the "the same as QTcpSocket
and QProcess." ? Behavior of QProcess from the Windows platform, or
behavior of QProcess from the *nix platform? :)

For me it is more pleasant, simpler, more logical, to implement a common
behavior (for any platform) as in Windows. Because in other case, the
bytesWritten()  loses the sense; becomes a ballast which doesn't bear the
useful sense.

BR,
Denis


2014-04-28 0:34 GMT+04:00 Thiago Macieira <thiago.macieira at intel.com>:

> 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
>
> _______________________________________________
> 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/05c38dab/attachment.html>