[Interest] readyRead() signal issues with QTcpSopcket and Qt 5.6 under minGW

[Etienne Sandré-Chardonnal]

The command itself is not consuming CPU time. But answers from the server
that need to be processed are (really) CPU consuming (such as one second of
CPU time). This happens later on and is not involved here so I have
stripped out that detail.

I have tried to reconstruct a minimal application doing the same, and I
could not reproduce the bug. So I will have to strip the main application
part by part in order to make one. This will take some time but I will do
it.

Regards,

Etienne

2016-07-11 18:05 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:

> On segunda-feira, 11 de julho de 2016 15:47:17 PDT Etienne
> Sandré-Chardonnal
> wrote:
> > Hi Thiago,
> >
> > After further investigation, the issue is not related to TCP but to
> > threads/events. It's on client (ie sender) side.
> >
> > I have the following order of events :
> >
> > Client * client = new Client(host, this);
> > QThread * clientThread = new QThread(this);
> > client->moveToThread(clientThread);
> > connect(this, SIGNAL(sendClientCommand(QString)), client, SLOT(command(
> > QString)));
>
> Does the command(QString) really take that much CPU time to create the
> command
> message to be sent over the socket that you need it to run on a separate
> thread?
>
> And by "that much", I mean A LOT of CPU time. If you can't say that is the
> case, stop using threads.
>
> > So I have a signal connected to an object's slot in another thread. I
> emit
> > the signal before the thread is started. I do not know if this is
> correct,
> > but :
> >
> >    - With Qt 5.4 the command("loadstart") slot is properly called as soon
> >    as possible
> >    - With Qt 5.6 the slot is not called until I emit the signal again, as
> >    if the event was queued, but the queue not processed until another
> event
> > is sent.
>
> Ok, that description sounds like a really serious event dispatching issue.
> Can
> you reduce this to a testcase?
>
> > Also, if I add a Client::threadStarted() slot calling processEvents() and
> > connect it to QThread::started() slot of clientThread, then the command
> > slot is processed on time. I do not know if this is an effect of
> > processEvents() or if this is because the connection is also queued, thus
> > waking up the event loop.
> > Can this be a Qt bug or am I misusing the queued connection?
>
> Your description makes it sound like a serious Qt bug. That's why I need
> the
> testcase.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160711/756f4702/attachment.html>