[Qt-interest] signals, sender(), and threads...

[BRM]

----- Original Message ----

From: Gordon Schumacher <gordon at rebit.com>
BRM wrote:
> > I have a network server program that I am porting from C/C++ to Qt to take advantage of Qt's threading, networking, and signal/slot functionality.
> > In the original program, each client was assigned its own handling thread.
> > The Qt version is using signals and slots and threads to handle the client communications, but some of the functionality is getting brought back to slots
> > in the main program (also okay, and actually resolves some other issues related to global information).
> > Each client connection has a QTcpSocket handled in a thread. The thread is has an instance object, which is run using a QThread derived class.
> > The thread uses signals/slots to communicate between things; and the instance object adds some extra functionality.
> In the documentation (at least for v4.5.2) they detail when sender() is
> not valid.  It sounds to me like what you really want is a synchronous
> notify/response between the two classes, yes?  In that case I'd suggest
> connecting the "notify" signal with Qt::BlockingQueuedConnection; that
> way you should not ever run into the conditions they detail above.  (You
> shouldn't be using DirectConnection between threads anyway!)
> An additional thought on the "response" portion... take a look at
> QMetaObject::invokeMethod() - it seems like a reasonable way to allow
> you to send "response" events either directly or via connect()'ed signals.

I all connections are made via default - so autoconnection, which means queued connections.
I very rarely do anything explicitly - and even then, it is typically to ensure they are queued.

I think my issue was that it was not clear whether it was explicitly only direct connections,
or if there were other circumstances in which it might also happen. Thanks for the clarity.

Thanks,

Ben