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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
