QObject cross-thread timer failure: queued versus direct signal delivery under concurrent workers

Direct answers

Queued delivery to one receiver becomes the bottleneck when aggregate emission throughput exceeds the receiver event loop's ability to dispatch plus run the slot. There is no universal emission rate; the crossover is workload specific to slot cost, payload copy cost and event-loop load. DirectConnection removes event-loop serialization but moves locking, reentrancy and receiver lifetime responsibility to the emitter threads.

Moving the receiver into a dedicated QThread does not change ordering guarantees. Queued delivery still preserves per-sender emission order and provides no cross-sender total order. It only relocates the serialization point off the GUI/main thread, which improves responsiveness but not aggregate throughput.

Separate event-loop queuing delay from worker-pool contention with three measurement points: emit timestamp vs slot entry timestamp for queuing delay, receiver event-loop backlog or idle ratio for serialization, and worker-side mutex hold/wait time near emit points for pool contention.

Confirmed facts

• A QObject has thread affinity. QTimer and sockets must be created, started and stopped in the owning thread. Use from another thread is documented unsupported behavior.
• With Qt::AutoConnection, a signal from a worker thread to a receiver in another thread becomes Qt::QueuedConnection. The slot is posted as an event and runs later in the receiver thread's event loop.
• Qt::DirectConnection executes the slot synchronously in the emitter's thread.
• Queued delivery serializes all N workers' emissions onto one event loop.

Likely explanation for tail latency

Under concurrent bursts tail latency is likely from event-loop serialization and per-event posting overhead, not from thread affinity alone. If the receiver slot is cheap but emissions are high rate, the queue grows and queuing delay dominates. If the slot is expensive or holds locks, dispatch-plus-slot rate limits throughput. Coarse mutexes near emit points add worker-pool contention that looks like queuing delay.

Steps needed for this case

1. Confirm thread affinity. Ensure the receiver QObject lives in the intended thread and timers/sockets are never started or stopped from workers.
2. Instrument a minimal repro with N workers emitting at controlled rates. Log emit timestamp and slot entry timestamp to measure queuing delay directly.
3. Measure receiver event-loop utilization: events processed per second vs events posted per second. Saturation indicates serialization bottleneck.
4. Test batching. Emit one signal per chunk of results instead of per result. If tail latency collapses, per-event posting overhead is the dominant factor.
5. Only consider DirectConnection if you can guarantee receiver lifetime across all workers and add explicit synchronization for shared state. Otherwise prefer a lock-free or mutex-protected queue drained by the receiver.

One missing diagnostic detail that changes the recommendation: the measured per-slot execution time and peak emissions per second on the actual workload. Without those numbers the queued vs direct decision cannot be made safely.