[P1][audio] Simplifier Stop et Abort autour d’un propriétaire de cycle de vie unique #6

New issue

Closed

opened 2026-07-31 21:05:10 +00:00 by mathieu · 1 comment

mathieu commented

2026-07-31 21:05:10 +00:00

Owner

Constat

Deux courses rendent l'état actuel ambigu (internal/audio/pwrecord/pwrecord.go:188-249, :307-350): un Abort() sans cause pendant Stop() n'est pas distingué de l'absence d'abort, et un second waiter Stop peut tuer le processus possédé par le premier appel lorsque son propre contexte expire.

Tâche

Modéliser explicitement abortRequested, réserver signal/kill au propriétaire de la transition et rendre les waiters purement observateurs. Éviter d'ajouter une nouvelle couche d'abstraction: simplifier l'automate existant.

Critères d'acceptation

Si Abort gagne avant validation, Stop ne retourne jamais de WAV.
L'annulation d'un waiter ne signale jamais le processus partagé.
Un seul appel possède la finalisation et les autres observent son résultat.
Les courses synchronisées passent 100 fois sous race.

Validation

go test -count=100 -race ./internal/audio/pwrecord

## Constat Deux courses rendent l'état actuel ambigu (`internal/audio/pwrecord/pwrecord.go:188-249`, `:307-350`): un `Abort()` sans cause pendant `Stop()` n'est pas distingué de l'absence d'abort, et un second waiter `Stop` peut tuer le processus possédé par le premier appel lorsque son propre contexte expire. ## Tâche Modéliser explicitement `abortRequested`, réserver signal/kill au propriétaire de la transition et rendre les waiters purement observateurs. Éviter d'ajouter une nouvelle couche d'abstraction: simplifier l'automate existant. ## Critères d'acceptation - Si Abort gagne avant validation, Stop ne retourne jamais de WAV. - L'annulation d'un waiter ne signale jamais le processus partagé. - Un seul appel possède la finalisation et les autres observent son résultat. - Les courses synchronisées passent 100 fois sous race. ## Validation `go test -count=100 -race ./internal/audio/pwrecord`

Rows
Columns