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

[Thiago Macieira]

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