[Mineur] `_energy_lock` tenue pendant tout le poll (10-20 s) : contention du consommateur stream #103

New issue

Open

opened 2026-08-26 05:33:46 +00:00 by mat · 0 comments

mat commented

2026-08-26 05:33:46 +00:00

Owner

Problème

coordinator.py:225-227 : le lock est pris autour de l'executor job complet (_fetch_all ≈ 10-20 s). Chaque poll gèle le traitement des bursts (_consume → async_integrate_live_energy → lock) pendant toute la durée ; les bursts s'accumulent dans une queue non bornée (stream.py:135).

L'intégration trapézoïdale supporte le gap, donc l'impact fonctionnel est faible, mais c'est de la contention gratuite.

Recommandation

Réduire la section critique : le lock n'est nécessaire qu'autour des mutations de _energy_state et de la sauvegarde, pas des appels réseau.
Ou Queue(maxsize=…) + drop-oldest côté producteur.

Constaté lors de la review de code pré-v1.0 (v0.8.1).

## Problème `coordinator.py:225-227` : le lock est pris autour de l'executor job **complet** (`_fetch_all` ≈ 10-20 s). Chaque poll gèle le traitement des bursts (`_consume` → `async_integrate_live_energy` → lock) pendant toute la durée ; les bursts s'accumulent dans une queue non bornée (`stream.py:135`). L'intégration trapézoïdale supporte le gap, donc l'impact fonctionnel est faible, mais c'est de la contention gratuite. ## Recommandation 1. Réduire la section critique : le lock n'est nécessaire qu'autour des mutations de `_energy_state` et de la sauvegarde, pas des appels réseau. 2. Ou `Queue(maxsize=…)` + drop-oldest côté producteur. --- Constaté lors de la review de code pré-v1.0 (v0.8.1).

mat added the

v1.0 · mineur

label

2026-08-26 05:33:46 +00:00