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.macie...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development