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

Denis Shienkov denis.shienkov at gmail.com
Mon Apr 21 14:50:50 CEST 2014


Hmmm..

Thiago, what do you mean by "writeable"? It is when device was opened in
the WriteOnly (ReadWrite) mode, or something else?

If I correctly understand, then I assume that the device always is
"writeable": i.e. opened in WriteOnly (ReadWrite) and the internal buffer
of writing is not empty.

(1) = Without flush ( and the seized moment between foo() and bar(), just
for example, as scenario )=

MyClass::foo()
{
dev.write('a');
dev.write('b');
}

MyClass::bar()
{
dev.write('c');
dev.write('d');
}

It is supposed that the notifier is fired after foo() and made syscall
::write(fd, 'ab') to the device (device driver), but before bar(). Also,
the 'ab' package was not really transferred yet (e.g. in time is
transferred only the 'a' part of package) to device, i.e. the Tx FIFO of
the driver didn't become empty yet.

I.e., there has to be such chain:

1. is called the foo()
2. add 'ab' to internal buffer and enable Tx notification (if was disabled)
3. some idle timeout (work in Qt-event loop)
4. fired the Tx empty event, that Tx FIFO is empty (if FIFO really was
empty)
5. write the 'ab' to device (the Tx FIFO of device/driver has 2 bytes)
6. the driver transferring one byte 'a' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'b' byte),
7. at this moment it is called the bar()
8. add 'cd' to internal buffer and enable Tx notification (if was disabled)
9. the driver transferring one byte 'b' from the Tx FIFO (the FIFO is
decreased by one byte, so, now is empty)
10. some idle timeout (work in Qt-event loop)
11. fired the Tx empty event (again), that Tx FIFO is empty
12. do emitting of the  bytesWritten( 2 byte )  signal (for 'ab' package),
that an data were *really* transferred
13. write the 'cd' to device (the Tx FIFO of device/driver has 2 bytes)
14. the driver transferring one byte 'c' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'd' byte)
15. the driver transferring one byte 'd' from the Tx FIFO (the FIFO is
decreased by one byte, so, now is empty)
16. some idle timeout (work in Qt-event loop)
17. fired the Tx empty event (again), that Tx FIFO is empty
18. do emitting of the  bytesWritten( 2 byte )  signal (for 'cd' package),
that an data were *really* transferred
19. stop Tx notification

I correctly describe it behavior? :)


(2) = With flush ( and the seized moment between foo() and bar(), just for
example, as scenario ) =:

MyClass::foo()
{
dev.write('a');
dev.write('b');
}

MyClass::bar()
{
dev.write('c');
dev.write('d');
dev.flush();
}

I.e., there has to be such chain:

1. is called the foo()
2. add 'ab' to internal buffer and enable Tx notification (if was disabled)
3. some idle timeout (work in Qt-event loop)
4. fired the Tx empty event, that Tx FIFO is empty (if FIFO really was
empty)
5. write the 'ab' to device (the Tx FIFO of device/driver has 2 bytes)
6. the driver transferring one byte 'a' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'b' byte)
7. at this moment it is called the bar()
8. add 'cd' to internal buffer and enable Tx notification (if was disabled)
9. forcibly to write the 'cd' to device (the Tx FIFO of device/driver has 3
bytes), the flush() do it
9. the driver transferring one byte 'b' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'cd' bytes)
10. the driver transferring one byte 'c' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'd' byte)
11. the driver transferring one byte 'd' from the Tx FIFO (the FIFO is
decreased by one byte, so, now is empty)
12. some idle timeout (work in Qt-event loop)
13. fired the Tx empty event (again), that Tx FIFO is empty
14. do emitting of the  bytesWritten( 4 byte )  signal (for 'abcd'
package), that an data were *really* transferred
15. stop Tx notification

I correctly describe it behavior? ;)


(3) = With flush ( an delay between foo() and bar() is not seized, just for
example, as scenario ) =:

MyClass::foo()
{
dev.write('a');
dev.write('b');
}

MyClass::bar()
{
dev.write('c');
dev.write('d');
dev.flush();
}

I.e., there has to be such chain:

1. is called the foo()
2. add 'ab' to internal buffer and enable Tx notification (if was disabled)
3. some idle timeout (work in Qt-event loop)
4. fired the Tx empty event, that Tx FIFO is empty (if FIFO really was
empty)
5. write the 'ab' to device (the Tx FIFO of device/driver has 2 bytes)
6. the driver transferring one byte 'a' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'b' byte)
7. the driver transferring one byte 'b' from the Tx FIFO (the FIFO is
decreased by one byte, so, now is empty)
8. some idle timeout (work in Qt-event loop)
9. fired the Tx empty event (again), that Tx FIFO is empty
10. do emitting of the  bytesWritten( 2 byte )  signal (for 'ab' package),
that an data were *really* transferred
11. stop Tx notification
12. Some idle period
12. is called the bar()
13. add 'cd' to internal buffer and enable Tx notification (if was disabled)
14. some idle timeout (work in Qt-event loop)
15. fired the Tx empty event, that Tx FIFO is empty (if FIFO really was
empty)
16. write the 'cd' to device (the Tx FIFO of device/driver has 2 bytes)
17. the driver transferring one byte 'c' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'd' byte)
18. the driver transferring one byte 'd' from the Tx FIFO (the FIFO is
decreased by one byte, so, now is empty)
19. some idle timeout (work in Qt-event loop)
20. fired the Tx empty event (again), that Tx FIFO is empty
21. do emitting of the  bytesWritten( 2 byte )  signal (for 'cd' package),
that an data were *really* transferred
22. stop Tx notification

I correctly describe it behavior? ;)

So, can be see, I assume, that emitting of the bytesWritten() should be
different for (2) and (3) scenario (with flush).. It is true? :)


(4) = With double flush (and the seized moment between foo() and bar(),
just for example, as scenario) =

MyClass::foo()
{
dev.write('a');
dev.write('b');
dev.flush();
}

MyClass::bar()
{
dev.write('c');
dev.write('d');
dev.flush();
}

I.e., there has to be such chain:

1. is called the foo()
2. add 'ab' to internal buffer and enable Tx notification (if was disabled)
5. forcibly to write the 'ab' to device (the Tx FIFO of device/driver has 2
bytes), the flush() do it
6. the driver transferring one byte 'a' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'b' byte)
7. at this moment it is called the bar()
8. add 'cd' to internal buffer and enable Tx notification (if was disabled)
9. forcibly to write the 'cd' to device (the Tx FIFO of device/driver has 3
bytes), the flush() do it
9. the driver transferring one byte 'b' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'cd' bytes)
10. the driver transferring one byte 'c' from the Tx FIFO (the FIFO is
decreased by one byte, and still contains the 'd' byte)
11. the driver transferring one byte 'd' from the Tx FIFO (the FIFO is
decreased by one byte, so, now is empty)
12. some idle timeout (work in Qt-event loop)
13. fired the Tx empty event (again), that Tx FIFO is empty
14. do emitting of the  bytesWritten( 4 byte )  signal (for 'abcd'
package), that an data were *really* transferred
15. stop Tx notification

I correctly describe it behavior? ;)



BR,
Denis


2014-04-21 6:56 GMT+04:00 Thiago Macieira <thiago.macieira at intel.com>:

> Em dom 20 abr 2014, às 22:13:47, Denis Shienkov escreveu:
> > == Second issue ==
> >
> > What about two scenarios ? (e.g. for some abstract I/O device):
> >
> > 1) Without flush():
> >
> > MyClass::foo()
> > {
> > dev.write('a');
> > dev.write('b');
> > }
> >
> > MyClass::bar()
> > {
> > dev.write('c');
> > dev.write('d');
> > }
> >
> > when, the bar() method were called after the foo(), when the Qt-event
> > loop was entered after foo().
> > i.e. for example both foo() and bar() are the buttons-clicked-handlers.
> >
> > then I expected to receive two: bytesWritten(2 byte) + bytesWritten(2
> > byte) signals
>
> That might not happen. It depends on whether the underlying device was
> writeable in the meantime and that the socket notifier did fire.
>
> > 2) With flush():
> >
> > MyClass::foo()
> > {
> > dev.write('a');
> > dev.write('b');
> > }
> >
> > MyClass::bar()
> > {
> > dev.write('c');
> > dev.write('d');
> > dev.flush();
> > }
> >
> > when, the bar() method were called after foo() (with some delay), but
> > when not all data ("a" and "b") was written (e.g. was in time written
> > only "a").
> > i.e. for example both foo() and bar() are the buttons-clicked-handlers,
> > but the bar-button-clicked in the moment when not all data was written
> > from the previous foo-button-clicked.
> >
> > then I expected to receive one bytesWritten(4 byte) signal
>
> flush() does not guarantee that any data gets written. It s equivalent to
> waitForBytesWritten(0), which will not write anything if the device is not
> writeable. And it won't block waiting for it to become writeable.
>
> > 3) With double flush():
> >
> > MyClass::foo()
> > {
> > dev.write('a');
> > dev.write('b');
> > dev.flush();
> > }
> >
> > MyClass::bar()
> > {
> > dev.write('c');
> > dev.write('d');
> > dev.flush();
> > }
> >
> > what here I expect to receive after all data will be really transferred?
> >
> > to receive two: bytesWritten(2 byte) + bytesWritten(2 byte) signals, or
> > to receive one bytesWritten(4 byte) signal ?
>
> Either is fine. See above: flush() does not guarantee that data gets
> written,
> since it won't block.
>
> --
> 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/20140421/2bc8c383/attachment.html>


More information about the Development mailing list