mirror of
https://github.com/esphome/esphome.git
synced 2026-09-15 17:18:40 +00:00
7ce49089a09b931918b374d871b30bda4a228111
The pre-sleep scan in Application::yield_with_select_() walks monitored_sockets_ on every loop iteration, issuing a volatile cross-thread read on each socket's lwip_sock::rcvevent to preserve select() semantics when the FreeRTOS task notification counter had been consumed but a socket still had unread data. That scenario only existed because of a Socket::ready() contract violation: callers could stop reading with rcvevent > 0, leaving data behind with no pending notification. That contract is now documented and enforced (#15590), and #15589 (the first failure that reverted the earlier removal attempt #14475) has been fixed. With the contract honoured, every rcvevent > 0 is paired with a pending xTaskNotifyGive from the lwip event_callback wrapper (see lwip_fast_select.c). ulTaskNotifyTake either returns immediately (counter non-zero) or wakes the moment the notify lands — the scan has nothing left to rescue. Evidence: https://github.com/esphome/esphome/pull/15638 — an instrumentation PR ran across 5 devices (ESP32 rev1/rev3.1/C3 on Ethernet and WiFi, plus LibreTiny RTL8720CF) through Home Assistant disconnect/reconnect cycles, multi-client API logger bursts, and BLE GATT connect storms. Across ~275,000 scans and 4 observed load-bearing candidates, every hit was in the 2–14µs range — the instruction-level window between the lwip callback writing rcvevent and calling xTaskNotifyGive a few instructions later. Zero hits exceeded 100µs. No hit came anywhere near loop_interval (16ms), which is the latency scale the scan was added to prevent. In addition to being unused, the scan is actively harmful on the hot path: N volatile 16-bit loads against cache-cold cross-thread lwip_sock structures on every main-loop iteration, just to reproduce a microsecond-scale ordering artifact the notification path is already handling authoritatively. This also removes the now-unused monitored_sockets_ vector and Application::{register,unregister}_socket() on the fast-select path. Socket implementations now call esphome_lwip_hook_socket() directly to install the netconn event callback wrapper.
Description
ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.
Readme
Multiple Licenses
597 MiB
Languages
C++
55.8%
Python
43.6%
C
0.3%
JavaScript
0.2%
