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

[Denis Shienkov]

Hi Thiago,

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

Hmm.. yes, in documentation it so. But actually it event triggered when
FIFO is empty. Well, ok, it isn't important, lets skip this issue now.. :)

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

Well, thanks a lot. I will take these arguments into account and we will
think what to do farther.

UPD: Guys, many thanks

BR,
Denis






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

> 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
>
> _______________________________________________
> 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/20140429/1e5a5f17/attachment.html>