[Interest] Thread stopped, signal ignored

[Etienne Sandré-Chardonnal]

> First of all, you do not need threads for that. QTcpServer and QTcpSocket work
> just fine in non-blocking mode, their default mode of operation.

I simplified, but the server worker object is also doing some
intensive work (actually this is cloud computing).

> Second, make sure that your QTcpServer was moved along with your worker object
> to the thread. That is, make sure that its parent is set to the object.
> Otherwise, you'll be doing really bad things.

It is! The QTcpServer is created in the Worker constructor, passing
this as parent.

> For those reasons, I recommend you simply rip out the threading code. You
> don't need it.

I really do! The threading is not for the QTcpServer itself, but for
the other calculations done by the server. This works very well, I
just encountered this issue while checking that everything destroys
correctly, and I was surprised that my "socket closed" qDebug was not
showing off. That's not a real issue as the socket will be closed when
the QTcpServer is destroyed, but I like to understand exactly how
things work to be as clean as possible...


> Because your assumption was wrong. The slot execution *was* queued before the
> thread quits. But there's no guarantee that it will get the chance to execute.
> QThread::quit() uses a separate mechanism to cause the quitting. It's not an
> event. Therefore, it's not synchronous to the execution of queued slots. Your
> code probably did the following (from the main thread's point of view):

Ah OK, I thought this was an event.
Now I trigger the QThread::quit slot from a signal emitted within
Worker::close(), this ensures that things are properly sequential
Thanks for the explanation!

Etienne