regarding Qt::BlockingQueuedConnection

[sattu]

The whole concept of signal and slot is "fire and forget". Qt::BlockingQueuedConnection is just spatial case needed only when slot should return some value (for example in some cases of DBus usage). When you don't send data back from slot to signal then use of BlockingQueuedConnection is redundant.

Correct. But when I need to know in sender thread whether slot(in receiver thread) has finished executing or not, then the only option is BlockingQueuedConnection, right? Yes, the slot is not returning any value, but at the same time signal should wait until the connected slot has finished executing. So, is there any other alternative for such scenarios?

---

Added after 37 minutes:

I'm asking you why you want to wait.

Well, the scenario is little bit complex but still I will try to explain.
SCENARIO-- I have a sensor thread and a tcp-client thread. Whenever sensor captures some biometric data, it will send the captured data to the tcp-client thread. The tcp-client will in turn send the biometric information to a remote authentication server which will respond with a "yes" or "no". When the tcp-client thread(which is waiting for the remote server's response) gets the response from server, it will immediately relay it back to the sensor thread. So, I require 2 pairs of signal-slot connection. One for sensor-to-tcpclient and another for the reverse.
PROBLEM-- But until tcp-client hasn't replied with the authentication response, sensor thread should wait. This is where my confusion begins .
MY APPROACH-- Since using of 2 BlockingQueued Connection was out of question, so I solved it temporarily by using a boolean variable in my sensor class i.e once I have sent the data to the tcpclient class the variable becomes true and it won't become false until the time I haven't got the response back from tcpclient.

But I am sure there must be a much better way to achieve the same. Like just now I saw that there is a method in tcpclient class which is :-

waitForReadyRead ( int msecs )

.
Sorry for taking such a long time to reply but all the way I was thinking how to reply in a very short and precise way

---

Added after 8 minutes:

Or maybe instead of taking a separate thread for tcpclient, I can directly declare it's object in my sensor class and connect it's readyread() signal with a slot of sensor class. So after doing

objClient->write(sendData);

objClient->write(sendData);

To copy to clipboard, switch view to plain text mode 

I can call

objClient->waitForReadyRead();

objClient->waitForReadyRead();

To copy to clipboard, switch view to plain text mode 

which will cause my sensor thread to hang until I haven't received response from server. Once I have received the data my readyreadslot() will immediately be called and I can get the response in the sensor class only.