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

[Denis Shienkov]

Hi Thiago,

> That's simply not workable.

> If the buffer never empties, bytesWritten() would never fire. Imagine the
user
> is always writing data at the same speed as the device is transmitting (or
> faster).

Hmm.. Yes. But this scenario it is possible in case of continuous flushing
(or, maybe with waitForBytesWritten(), not sure).
Because only the flushing can adds data to the FIFO of driver directly ,
e.g:

connect(timer, SIGNAL(timeout()), this, SLOT(fooSlot()));

MyClass::fooSlot()
{
dev.write();
dev.write();
dev.write();
dev.flush();
}

where an timer has an zero (0) interval (for example to continuous writing)
and only on POSIX-compatible platforms.In other cases (and on Windows with
using overlapped I/O it will be fine), IMHO.

So, here are dilemma:

1. or keep it as is, but then bytesWritten() will be "tell lies"
2. or modify it (as I offer), but then bytesWritten() can never fired (as
you say)

It is bad. Because (concerning to QSerialPort) if to keep as is, then
implementation of bytesWritten() in Windows will be correctly work, but
implementation in POSIX will be lies...
i.e. we can't get an identical behavior on different platforms anyway, i.e.
the user can be confused.

Bad bad bad... :)

BR,
Denis





2014-04-22 18:42 GMT+04:00 Thiago Macieira <thiago.macieira at intel.com>:

> Em ter 22 abr 2014, às 12:28:39, Denis Shienkov escreveu:
> > If to be honest, I don't agree with implementation with emission of the
> > bytesWritten() signal in QAbstractSocket. IMHO, this signal has to be
> > emitted when data were really transferred, i.e. after completion of
> > transfer, when fired the Tx-empty notifier. But not after the calling of
> > non-blocking write(fd, ..). Probably, for high-speed interfaces (like
> > sockets) it is noncritical, but for the serial port it is critical.
> Because
> > exist, for example, the hardware RS-485 devices where the direction of
> > transfer is switched by DTR signal. Thus, it is important to know when
> data
> > transmission is really finished to switch to reception. For this purpose
> it
> > is possible to use bytesWritten(qint64) signal. BUT, in case same
> > implementation as in QAbstractSocket, we got an fail, because
> > bytesWritten() will tell lies to us.
>
> That's simply not workable.
>
> If the buffer never empties, bytesWritten() would never fire. Imagine the
> user
> is always writing data at the same speed as the device is transmitting (or
> faster).
>
> --
> 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/20140422/02aa61ff/attachment.html>