[Interest] Thread guarantee on slots+timers

Sensei senseiwa at gmail.com
Mon Apr 14 12:54:29 CEST 2014


On 4/11/14, 10:26am, André Somers wrote:
> Not quite, and it is not such a simple question at all. It depends on
> which thread actually triggers the slot, and how. If you were to trigger
> the slot, either by a direct method call or using a direct connection,
> from two different threads, there are no guarantees of it being run
> consequtively. It may run twice at the same time from two different
> threads, or interleaved, or... There is just no telling.

Thanks André, your point is clear.


> If your slot is exclusively ran in a single thread, either because it is
> only triggered from that thread or because you use queued connections
> from other threads to trigger it, it will be ran consecutively for each
> invocation. However, invocations that find their source in the event
> queue (timers, but also queued connections) may be triggered later than
> those that result from direct method calls or direct (or automatic,
> within the same thread) connections. This is because the event  queue is
> only processed again if you return to it. Before that, timer events or
> queued signals are not processed and thus don't trigger the slots.


Ok, so I need to enforce exclusivity if I need that. Actually the slot 
is called by two means:
- thread itself via QTimer
- main GUI thread via signal/slot

Do you see a potential threat to the GUI (responsiveness) if I use a 
QMutex to serialize execution by force?


Thanks!



More information about the Interest mailing list