Re: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix?
01.03.2017, 13:28, "Denis Shienkov" :
> Hi all,
>
> I have use Qt 5.8, and I want to send to the UDP socket many datagrams
> (e.g. 1 datagrams, each datagram have 1000 bytes size).
Totally unrelated to your main issue, but make sure you are using connected UDP
socket when sending many datagrams to same host, it should improve performance
>
> I use following code:
>
> int busyCounter = 0;
> for(;;) {
> ...
> const QNetworkDatagram datagram(data, m_remoteAddress,
> Protocol::SlavePort);
> if (m_dataSocket->writeDatagram(datagram) == -2) {
> QElapsedTimer timer;
> timer.start();
> const bool result = m_dataSocket->waitForBytesWritten(-1);
> ++busyCounter;
> qDebug() << "Wait result:" << result << "nsecs:" <<
> timer.nsecsElapsed() << "busy counter:" << busyCounter;
> } else {
> busyCounter = 0;
> break;
> }
> }
>
> As I understand, when I got the EAGAIN error (when the writeDatagram() method
> fails
> with the error code == -2), it means, that the transmit queue is full, and I
> need wait
> for something time, e.g. using the select() function:
>
> https://linux.die.net/man/2/sendmsg
>
> "
> When the message does not fit into the send buffer of the socket, send()
> normally blocks, unless the socket has been placed in nonblocking I/O mode.
> In nonblocking mode it would fail with the error EAGAIN or EWOULDBLOCK in
> this case. The select(2) call may be used to determine when it is possible to
> send more data.
> "
>
> and then, as I understand, I need try to send same datagram again.
>
> Instead of the select() I use the QUdpSocket::waitForBytesWritten() method,
> which uses the select/pool/epoll internally.
>
> But, seems it does not work, as described in the POSIX documentation,
> I got following debug output:
>
> "
> Wait result: false nsecs: 363 busy counter: 1
> ...
> Wait result: false nsecs: 140 busy counter: 232
> ...
> Wait result: false nsecs: 167 busy counter: 1
> ...
> Wait result: false nsecs: 139 busy counter: 238
> ...
> Wait result: false nsecs: 167 busy counter: 1
> ..
> Wait result: false nsecs: 167 busy counter: 19
> ...
> "
>
> and etc.
>
> I suspect, that the busyCounter always should be 1, but it does
> not happens, and the waitForBytesWritten() always fails!
>
> What doing wrong?
>
> BR,
> Denis
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix?
Hi Thiago,
> QAbstractSocket::waitForBytesWritten ... This isn't needed and isn't
useful.
> QUdpSocket is unbuffered, so the bytesWritten() signal is not useful.
> You don't get to poll(). See above.
Goood news! :)
So, should I create an own wrapper (QIODevice) for the UDP socket? Or there
is a solution with QUdpSocket?
> ...unless QUdpSocket already creates one on that socket. The event
dispatcher
> does not allow two QSN on the same socket, with the same type. If that
> happens, let us know.
Ok, I will try to check it.
BR,
Denis
2017-03-01 23:17 GMT+03:00 Thiago Macieira :
> Em quarta-feira, 1 de março de 2017, às 02:27:54 PST, Denis Shienkov
> escreveu:
> > Hi all,
> >
> > I have use Qt 5.8, and I want to send to the UDP socket many datagrams
> > (e.g. 1 datagrams, each datagram have 1000 bytes size).
> >
> > I use following code:
> >
> > int busyCounter = 0;
> > for(;;) {
> > ...
> > const QNetworkDatagram datagram(data, m_remoteAddress,
> > Protocol::SlavePort);
> > if (m_dataSocket->writeDatagram(datagram) == -2) {
> > QElapsedTimer timer;
> > timer.start();
> > const bool result = m_dataSocket->
> waitForBytesWritten(-1);
>
> This isn't needed and isn't useful. QAbstractSocket::waitForBytesWritten
> has
> this:
>
> if (writeBuffer.isEmpty())
> return false;
>
> Since QUdpSocket is unbuffered, the write buffer is always empty. So
> waitForBytesWritten will always return false.
>
> > As I understand, when I got the EAGAIN error (when the writeDatagram()
> > method fails
> > with the error code == -2), it means, that the transmit queue is full,
> and
> > I need wait
> > for something time, e.g. using the select() function:
> >
> > https://linux.die.net/man/2/sendmsg
>
> Which is QSocketNotifier.
>
> QUdpSocket is unbuffered, so the bytesWritten() signal is not useful. We
> can't
> add a readyWrite() signal because it would be fired all the time. You'll
> have
> to do the QSocketNotifier.
>
> ...unless QUdpSocket already creates one on that socket. The event
> dispatcher
> does not allow two QSN on the same socket, with the same type. If that
> happens, let us know.
>
> > and then, as I understand, I need try to send same datagram again.
> >
> > Instead of the select() I use the QUdpSocket::waitForBytesWritten()
> method,
> > which uses the select/pool/epoll internally.
>
> You don't get to poll(). See above.
>
> --
> 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
Re: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix?
Em quarta-feira, 1 de março de 2017, às 02:27:54 PST, Denis Shienkov escreveu:
> Hi all,
>
> I have use Qt 5.8, and I want to send to the UDP socket many datagrams
> (e.g. 1 datagrams, each datagram have 1000 bytes size).
>
> I use following code:
>
> int busyCounter = 0;
> for(;;) {
> ...
> const QNetworkDatagram datagram(data, m_remoteAddress,
> Protocol::SlavePort);
> if (m_dataSocket->writeDatagram(datagram) == -2) {
> QElapsedTimer timer;
> timer.start();
> const bool result = m_dataSocket->waitForBytesWritten(-1);
This isn't needed and isn't useful. QAbstractSocket::waitForBytesWritten has
this:
if (writeBuffer.isEmpty())
return false;
Since QUdpSocket is unbuffered, the write buffer is always empty. So
waitForBytesWritten will always return false.
> As I understand, when I got the EAGAIN error (when the writeDatagram()
> method fails
> with the error code == -2), it means, that the transmit queue is full, and
> I need wait
> for something time, e.g. using the select() function:
>
> https://linux.die.net/man/2/sendmsg
Which is QSocketNotifier.
QUdpSocket is unbuffered, so the bytesWritten() signal is not useful. We can't
add a readyWrite() signal because it would be fired all the time. You'll have
to do the QSocketNotifier.
...unless QUdpSocket already creates one on that socket. The event dispatcher
does not allow two QSN on the same socket, with the same type. If that
happens, let us know.
> and then, as I understand, I need try to send same datagram again.
>
> Instead of the select() I use the QUdpSocket::waitForBytesWritten() method,
> which uses the select/pool/epoll internally.
You don't get to poll(). See above.
--
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
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
Em quarta-feira, 1 de março de 2017, às 04:38:47 PST, Marc Mutz escreveu: > > This also implies that bug fixes should now get pushed to the 5.9 branch > > and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? We usually switch the default branch between the beta and the RC, so the point is moot. 5.9 will be considered stable in a couple of weeks, so 5.8 can be closed. -- 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
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
> -Original Message- > [...] > > This also implies that bug fixes should now get pushed to the 5.9 > > branch and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can > close > 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? Why should a patch merged into 5.8 right now be a better candidate to cherry-picking than one merged into 5.9? It runs through the same scrunity (CI). IMO it's actually harmful to keep 5.8 open if we don't intend to make a release based on it. We keep the overhead of maintaining and merging multiple branches without any benefit. My 2 cents, Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
> So let me play the devil's advocate: 5.9.1 also will be canceled for > similar arbitrary reasons like vacation plans. or the universe might end for no readily apparent reason. There is no reason to expect either will happen, though. > Guys, by not delivering bugfix releases for arbitrary reasons we are > risking to kill Qt's credibility as reliable toolkit. Our users trust in > getting bugfix releases. I think it's been made abundantly clear that * there are concrete practical non-arbitrary reasons in this case, * we have a clear plan for how to fix the causes, * there is a clear intent to not skip further releases. This is a one-off caused by problems we do anticipate resolving; and skipping 5.8.1 is how we'll buy the time to resolve them, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
Am 18.02.2017 um 21:40 schrieb Thiago Macieira: On sábado, 18 de fevereiro de 2017 11:49:28 PST Konstantin Tokarev wrote: 18.02.2017, 22:13, "Thiago Macieira" : On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned release date would seem to be appropriate when you have the capability to concurrently maintain two minor (not patchlevel) release branches. That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, because of that, 5.8.1 becomes impossible and unnecessary. So people who cannot upgrade to 5.8.0 because of bugs would have to wait for 5.9.0 and hope that there will be no other regressions. Great. Or wait for 5.9.1. So let me play the devil's advocate: 5.9.1 also will be canceled for similar arbitrary reasons like vacation plans. Guys, by not delivering bugfix releases for arbitrary reasons we are risking to kill Qt's credibility as reliable toolkit. Our users trust in getting bugfix releases. Ciao, Mathias -- Mathias Hasselmann | mathias.hasselm...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325485 / +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
Am 01.03.17 um 13:38 schrieb Marc Mutz: > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: >>> Let’s conclude this topic now by moving on towards 5.9 as Tuukka >>> proposed. After some thinking I also agree that this is the best course >>> of action from where we are right now. >> This also implies that bug fixes should now get pushed to the 5.9 branch >> and we should close the 5.8 branch soon. > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? > > Thanks, > Marc > +1 from me just cherry-picked from 5.8 to get a Show-Stopper-Bug fixed https://appbus.wordpress.com/2017/02/28/patch-qt-5-8-0-for-qtbug-59026/ -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps *Qt Champion BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:e...@ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka > > proposed. After some thinking I also agree that this is the best course > > of action from where we are right now. > > This also implies that bug fixes should now get pushed to the 5.9 branch > and we should close the 5.8 branch soon. I disagree. Even if you cannot produce releases from 5.8 anymore, that's our stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
> On 01 Mar 2017, at 08:58, Lars Knoll wrote: > > Hi, > > sorry for answering only now to this thread, I was on vacation last week. > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka proposed. > After some thinking I also agree that this is the best course of action from > where we are right now. This also implies that bug fixes should now get pushed to the 5.9 branch and we should close the 5.8 branch soon. Cheers, Lars > > This is certainly not a great solution, ideally we should have the capability > of making both 5.9 in time and push out 5.8 and 5.6 patch level releases. > This is currently not working and I’ll be following up on this. My goal is to > make sure we identify all the issues in our current release infrastructure, > fix at least the worst things that make creating patch level releases > difficult until 5.9, and have a clear roadmap for the remaining items. I > really don’t want this to happen again. > > The other thing I’ll take from this is to have another look at the > interaction between TQtC and the Qt project. I do see a conflict here in how > we handle the release planning between the Company and the Project, and we’ll > need to find a better (or more clearly defined and agreed) way on how we > jointly create the release roadmap. > > Cheers, > Lars > >> On 20 Feb 2017, at 13:56, Tuukka Turunen wrote: >> >> >> >>> On 18/02/2017, 21.40, "Development on behalf of Thiago Macieira" >>> >> thiago.macie...@intel.com> wrote: >>> >>> On sábado, 18 de fevereiro de 2017 12:11:53 PST Mat Sutcliffe wrote: On 18 February 2017 at 19:13, Thiago Macieira My point was that this decision happened already on 29 November. That was the original planned release date for 5.8.0, and also the day on which the 5.9.0 initial schedule was set. Could it have been predicted at that time what the consequences might be for 5.8.1? >>> >>> Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. >>> >>> The question is only what to do now. >> >> What I hope we can do is to have everyone helping to get Qt 5.9.0 out as >> soon as possible and then make also 5.9.1 soon (although I think we do need >> to make 5.6.3 in between). >> >> If we can have the extra help proposed by KDAB and others in the community >> for making Qt 5.8.1 release geared towards making Qt 5.9 we will be able to >> make it faster and with higher quality than otherwise possible. >> >> One concrete item is manual testing of our various snapshots. The sooner >> these are fully tested, the better. We have CI and RTA test automation, but >> these do not cover every aspect. Manual testing is needed as well. Often it >> is a case that a bug is found in quite late release steps, but has actually >> been there for some time already. Another way to help is making good bug >> reports that are also notified to the release team. The better the >> description of the issue, the easier it is to fix it. Third item is of >> course fixing things quickly – by having more people fixing the issues >> identified we will be able to close them sooner and thus proceed faster. >> >> For the CI stability most important thing is to reduce the amount of flaky >> test cases, which cause failures in CI runs. This in turn both adds delay as >> well as increases the load of the CI. >> >> Yours, >> >> Tuukka >> >> ___ >> 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] CI maintenance break next weekend 4 - 5 Mar 2017
Hi We have scheduled a maintenance break for the CI next weekend. This will cause the CI to be totally offline at least during Sat and could extend over Sun as well. We've planned to do extensive wipe or cleanup to local stored distro images. We have accumulated garbage over the years and the only way to find them is to do deep cleanup. We'll achieve this by wiping all provisioned images and re-cloning the important vanilla templates over to safe location. The builds that are triggered right after we come back online will re-create the provisioned images back again. We will also update vSphere while at it. Regards, -Tony ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix?
Hi all,
I have use Qt 5.8, and I want to send to the UDP socket many datagrams
(e.g. 1 datagrams, each datagram have 1000 bytes size).
I use following code:
int busyCounter = 0;
for(;;) {
...
const QNetworkDatagram datagram(data, m_remoteAddress,
Protocol::SlavePort);
if (m_dataSocket->writeDatagram(datagram) == -2) {
QElapsedTimer timer;
timer.start();
const bool result = m_dataSocket->waitForBytesWritten(-1);
++busyCounter;
qDebug() << "Wait result:" << result << "nsecs:" <<
timer.nsecsElapsed() << "busy counter:" << busyCounter;
} else {
busyCounter = 0;
break;
}
}
As I understand, when I got the EAGAIN error (when the writeDatagram()
method fails
with the error code == -2), it means, that the transmit queue is full, and
I need wait
for something time, e.g. using the select() function:
https://linux.die.net/man/2/sendmsg
"
When the message does not fit into the send buffer of the socket, *send*()
normally blocks, unless the socket has been placed in nonblocking I/O mode.
In nonblocking mode it would fail with the error *EAGAIN* or *EWOULDBLOCK*
in this case. The *select *(2) call may
be used to determine when it is possible to send more data.
"
and then, as I understand, I need try to send same datagram again.
Instead of the select() I use the QUdpSocket::waitForBytesWritten() method,
which uses the select/pool/epoll internally.
But, seems it does not work, as described in the POSIX documentation,
I got following debug output:
"
Wait result: false nsecs: 363 busy counter: 1
...
Wait result: false nsecs: 140 busy counter: 232
...
Wait result: false nsecs: 167 busy counter: 1
...
Wait result: false nsecs: 139 busy counter: 238
...
Wait result: false nsecs: 167 busy counter: 1
..
Wait result: false nsecs: 167 busy counter: 19
...
"
and etc.
I suspect, that the busyCounter always should be 1, but it does
not happens, and the waitForBytesWritten() always fails!
What doing wrong?
BR,
Denis
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
