Question

I have a ‘producer’ object, that steps through some data and emits various signals depending on what data item is next in the queue.

Each of those signals are processed by at most one ‘consumer’ object at a time (it takes care to disconnect its slots before attaching the producer’s signals to the other consumer).

If the processing on the consumer side fails for whatever reason, the processing of the queue must stop, as there is no point in going ahead with it.

What would be the optimal way of letting the producer know, that no further processing is needed because of an exceptional condition? Since the consumers have a pointer to the producer, I would imagine, that there could be multiple ways, its just that I am not sure if they are race-condition-safe (I don’t know if I can depend on the order in which signals are emitted / processed).

Two ways I can think of:

• set a flag on the producer, that can be checked on the next iteration so that it will know that it is time to stop
• register a signal on the consumer (and a corresponding slot on the producer), that will be emitted when processing should be halted

I am wondering if these solutions are viable at all in the following scenarios:

• producer and consumer(s) belong to the same thread
• producer and consumer(s) belong to different threads

In short, I have to make absolutely sure, that no additional processing will happen if the consumer reports an error.

As you can probably guess, I am not very familiar with Qt’s idioms for such things yet.

Answer 1

You have a couple of inter-related questions.

To me, the most important question is related to signal/slots working with threading.

When using signal/slots within a single thread, Qt by default assumes a AutoConnection or “direct” connect. In direct connect mode, signal/slots acts almost exactly like a callback function. Meaning that the function emitting the signal essentially executes a subroutine call.

When transferring signal/slots across threads, Qt by default assumes a QueuedConnection by default. What happeans here is complicated. Sequence is –

1. Emitted Signal is recieved by the QApplicationCore.
2. Core makes a deep copy of the arguments in the data space of the slot receiving thread.
3. Control is returned to function that emitted the signal.
4. Core calls the slot when it can based on the event queue.

So knowing this, back to your original question, how to know when the slot function has stopped processing? Qt doesn’t have an idiom that I’m aware of how to pass this information back. But the idiom with Qt signal/slots is the signalling thread should know nothing about how the slot function or how what the connection type is.

So my recommendation would be to pass the data via a pointer to the data to be processed. In the data, I would add two fields –

1. A result flag. At a minimum, this should include states for “Not Started”, “Completed”, “Completed w/errors” and “Function Aborted”. The “Function Aborted” flag would be set in the catch block of a try/catch block.
2. A watchdog timer field based on QDateTime set to current date/time when signal is emitted. If the signalling thread uses this value to determine if the consuming thread has completely failed.

Using this approach –
– There is no reason that the calling thread has to have any direct knowledge of the signalling thread.
– There is nothing in this structure that needs to change if you go from single threaded or multiple threaded.

Hope this helps with your problem. This is the approach we are currently using in our shop.