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

Qt documents that a QObject has thread affinity: timers and sockets must be created, started and stopped in their owning thread, and use from another thread is a documented failure condition, not a portable guarantee. Cross-thread signals follow a related rule: with Qt::AutoConnection, delivery becomes queued, so the slot runs later in the receiver thread's event loop.

The open decision is a delivery strategy for N worker threads emitting high-rate results to one receiver object. Queued delivery is simple and ordered but serializes every emission on a single event loop; Qt::DirectConnection executes in the emitter's thread and shifts locking, reentrancy and lifetime responsibility to the caller.

Under concurrent bursts, tail latency could come from event-loop serialization, per-event posting overhead, or coarse mutexes near emit points. Connection-type defaults are broadly stable across Qt 5 and Qt 6, but module-specific behavior should be confirmed against the exact version in use.

1. At what emission rate does queued delivery to one receiver thread become the bottleneck versus direct callbacks with explicit synchronization?
2. Does moving the receiver into a dedicated QThread change ordering guarantees, or only relocate the serialization point?
3. Which measurement points best separate event-loop queuing delay from worker-pool contention?