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

[Thiago Macieira]

Em seg 28 abr 2014, às 17:04:31, Denis Shienkov escreveu:
> 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.

No, it isn't. The socket notifier activates when there's buffer available in the 
kernel, not that the buffer is empty. That means something got flushed, but it 
does not indicate that everything did.

I will ask very specifically: what ioctl or fcntl do you need to enable to get 
the notification? If you don't know the answer to this, I assert that you don't 
have a tx-empty event.

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

The Windows behaviour is only that because of either:

a) a bug
b) the Windows kernel keeps referring to our buffer and we can't completely 
flush it until we get the completion notification

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

This is the expected behaviour.

> 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? :)

The behaviour of QTcpSocket on all platforms and of QProcess on Unix.

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

That rests on the requirement that the behaviour you want to implement can be 
implemented. I have not seen any indication so far that it is possible for 
serial ports, let alone for sockets and pipes.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center