mirror of
https://github.com/esphome/esphome.git
synced 2026-09-02 02:56:01 +00:00
J. Nick Koston
da5c31cb27
On multi-thread platforms (ESP32/LibreTiny/host), defer() items go directly into a separate defer_queue_ instead of the main items_ heap (scheduler.cpp:200). next_schedule_in previously only looked at items_[0], so a pending defer posted from a background task was invisible to the loop's sleep-duration calculation: if items_[0] fired seconds away, the main loop would sleep that long on ulTaskNotifyTake while the defer sat unexecuted. In practice this rarely bit anyone because concurrent socket activity usually woke the loop via the lwip fast-select path, but a defer with no accompanying network traffic could stall for seconds. Check defer_empty_() (cheap atomic/volatile load, scheduler.h:594) before the items_ check and return 0 if pending. process_defer_queue_ runs at the top of every scheduler.call(), so "defer pending" == "run immediately." Single-threaded platforms funnel defers into to_add_ like any other timeout, so the fix is gated on !ESPHOME_THREAD_SINGLE.
