[Feature]: Event based system indication queue polling

[aferaudo]

Problem / use case

LockFreeQueue::pop()'s adaptive back-off degenerates into a fixed-period poller for the E3 indication path. Two things make it worse than intended: the wait is dominated by Linux default timer slack rather than by SLEEP_DURATION, and pinning the io thread via io_thread_affinity increases it.

       // Phase 3: Short sleep until data arrives or shutdown is signalled
        while (true) {
            if (ring_.try_pop(item)) return item;
            if (shutdown_.load(std::memory_order_relaxed)) return T{};
            std::this_thread::sleep_for(SLEEP_DURATION);
        }

Traffic Environment
Traffic: one INDICATION_MESSAGE per UL slot, 1200 msg/s (833 µs period), 271-byte PDUs, JSON encoding.

SLEEP_DURATION	distribution	mean	p50	p95	ceiling
50 µs (default)	flat uniform 0…105 µs	52.60	52.31	100.51	~105 µs
5 µs	flat uniform 0…60 µs	29.13	28.43	57.00	~60 µs

Problem specific to pinning one core
Wall-clock duration depends entirely on whether another runnable thread exists on that core. On a dedicated core with nothing else runnable, std::this_thread::yield() returns in ~200 ns, the thread may fall into the sleep path for the remaining ~800 µs of the gap. So io_thread_affinity pointed at an isolated core produces the worst case, which is the opposite of what the knob is for.

In OAI this does not happen as it share an already busy core.

Proposed solution

notify-on-push: the producer signals a condvar/futex in push(), the consumer blocks in pop(). The wait becomes wake latency (~3–5 µs) instead of a poll period, and it stops depending on thread placement and on timer slack.

Alternatives considered

No response

Twin-repo impact

None

ABI / API impact

No change to public headers

Are you willing to implement this?

Yes, with maintainer guidance

Additional context

No response