Allow me to revive this topic, since more than a decade later it is still as relevant as ever.
@andre said in Signal/slot across threads - remove duplicate events in event loop:
In the past, I have throttled the delivery of update messages from a worker to the GUI thread to at most two per second, and that worked very well for me.
This isn't a proper solution, because it relies on a wild guess about the time needed for the consumer to consume. One day you'll have your code run on a machine on which the GUI thread takes more than 0.5 s to process a request, and boom, unbounded queue growth.
If the receiver is the GUI thread (and thus the events that you send there are just to refresh the GUI), the proper way is to have the GUI thread reply to the worker thread with ACKs.
In the worker class:
Have a boolean variable called "SignalRequested" or something like that. It doesn't even have to be atomic.
Have a slot that will assert this boolean, called "RequestSignal" or something like that.
Inside the producer loop, check this boolean, and if it's true, reset it back to false and emit the signal.
In the GUI class:
Invoke the RequestSignal slot on the worker during startup.
Wherever you receive the signal from the worker, refresh the UI and start a single-shot timer connected to the RequestSignal slot on the worker. The timer's interval will determine the GUI's refresh rate.
There you go, an effective solution that'll guarantee at most a single undelivered signal at all times.
If the receiver is not the GUI thread, the only proper way is to make your own queue (at least until Qt provides us with means to control its internal one).
Write a RingBuffer class (check Wikipedia for examples).
Instantiate it with the type of your event.
Protect this instance with a mutex.
Add a WaitCondition.
Implement the classic producer/consumer pattern.
Voila: now, in the Producer thread, you can actually assess the situation whenever you are going to add an event to the queue and do some meaningful things if the queue grows too much - issue a warning, drop the event, etc., instead of blindly shoving events into the queue and hoping for the best.
