run_loop::state_t::pop() wakes up prematurely

[nomevas]

The predicate in the second cv.wait_for is incorrect:

m_cv.wait_for(lock, m_queue.top()->get_timepoint() - now, [&]() { return is_disposed() || !m_queue.is_empty() || m_queue.top()->get_timepoint() <= worker_strategy::now(); });

!m_queue.is_empty() is "always" true at this point, because we’re already in a scope where that condition has been checked. As a result, the predicate immediately evaluates to true, making the wait return right away and causing a busy loop. This leads to high CPU usage when using interval operators combined with run loops.

Fix suggestion, change predicate to:

m_cv.wait_for(lock, m_queue.top()->get_timepoint() - now, [&]() { return is_disposed() || m_queue.is_empty() || m_queue.top()->get_timepoint() <= worker_strategy::now(); });

[AlexInLog]

Hey @nomevas, hmm, yeah, good catch! I think, change to m_queue.is_empty would be also incorrect due to if queue becomes empty -> we still need to wait for new appearances

[nomevas]

That shouldn’t be an issue. If the queue changes (e.g., items are removed), the condition variable should be released so the wait duration can be recalculated based on the new top element in the priority queue. The simplest solution is to loop once more and let the logic recompute the next wait time. One loop doesn't cost much.

[AlexInLog]

merged