Un deadlock au sens classique implique deux threads qui s'attendent mutuellement, chacun détenant une ressource dont l'autre a besoin. Mais il existe une variante plus subtile qui n'implique aucun thread -- un deadlock logique où une séquence d'opérations crée une dépendance circulaire qui empêche tout progrès.
FLIN a rencontré cette variante pendant le développement de son système d'actions. Le symptôme rappelait un processus écrivant dans un pipe stderr plein et se bloquant indéfiniment -- sauf que dans notre cas, c'était la VM rencontrant un opcode qu'elle ne comprenait pas et errant dans la mémoire du bytecode jusqu'à atteindre quelque chose qui provoquait un retour silencieux.
L'architecture du système d'actions
Le système d'actions de FLIN fait le pont entre l'interactivité du navigateur et la logique côté serveur. Le détail critique est que la VM est créée fraîche pour chaque requête d'action -- elle ne partage pas d'état avec la VM qui a rendu la page.
Le pattern du deadlock
Quand execute_until_return rencontrait l'opcode CreateEntity, elle ne trouvait pas de gestionnaire. Le cas par défaut avançait le pointeur d'instruction d'un octet -- mais CreateEntity est une instruction de quatre octets. Le PI avançait au milieu des opérandes de l'instruction. L'octet suivant était interprété comme un opcode. Le PI errait à travers le bytecode comme une aiguille sautant des sillons d'un disque.
Le système n'était pas figé au sens traditionnel -- il répondait promptement à chaque requête. Mais il était logiquement bloqué : l'utilisateur cliquait répétitivement sur « Add Task », le serveur exécutait répétitivement la fonction, et la fonction échouait répétitivement à créer une entité. Aucun progrès n'était possible.
Leçons du deadlock
Les tables de dispatch parallèles sont un risque de maintenance. Chaque fois que deux chemins de code doivent gérer le même ensemble de cas, ils dériveront inévitablement.
Les échecs silencieux nécessitent une détection proactive. Le compteur d'opérations d'entités était le diagnostic clé -- il ne vérifiait pas les erreurs mais l'absence de résultats attendus.
Testez le chemin de création séparément du chemin de modification. La création d'entités et la modification d'entités sont des opérations fondamentalement différentes même quand elles partagent la même couche de persistance.
Ceci est la partie 160 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [159] Le bug de rendu des espaces blancs HTML - [160] Quand la VM s'est bloquée sur la création d'entités (vous êtes ici) - [161] Le bug de suivi des versions temporelles