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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
