Présentation

Les notebooks Jupyter perdent habituellement l’état du kernel dès que le client se déconnecte. Le projet Tithon propose de décorréler le kernel du processus d’extension VS Code en le plaçant sur l’hôte. Ainsi, même après la fermeture du laptop ou la perte du réseau, le kernel continue d’exécuter le code et les sorties restent accessibles. Le projet est en version alpha, fonctionne quotidiennement et cible les environnements Linux où les développeurs utilisent des GPU distants via SSH.

Architecture

Tithon introduit un daemon écrit en Python 3.11+ qui s’exécute en arrière‑plan. Le daemon démarre le kernel ipykernel avec setsid, ce qui le détache de tout processus parent et le rend résilient aux crashs du daemon. La communication se fait exclusivement via un socket Unix (permissions 0600), éliminant toute exposition TCP. Chaque message iopub ou shell est journalisé mot‑pour‑mot dans une base SQLite en mode WAL, stockée sous $TITHON_HOME/sessions/.../journal.db. Les sorties riches (images, HTML) sont écrites comme fichiers séparés, indexés par leur hash SHA‑256, ce qui évite l’encodage base64 dans le notebook.

Fonctionnement

Le client VS Code charge un fichier .py au format « percent‑cells » et sélectionne le kernel Tithon. Les cellules sont exécutées via la commande 

tithon run -c 'x = 41'
ou 
tithon run -c 'x += 1; print(x)'
. Le daemon conserve la variable x entre les appels, ce qui se vérifie avec tithon status. En cas d’arrêt du daemon, le kernel reste actif ; la relance du daemon avec tithon daemon & réattache automatiquement la même session grâce au fichier de connexion persistant. L’option tithon attach --since 0 restitue l’historique complet, tandis que --since N ne rejoue que les événements postérieurs au numéro de séquence N, offrant un contrôle fin du flux de reprise.

Implications et limites

Le modèle repose sur un système Unix‑like ; Windows natif n’est pas supporté et nécessite WSL. La persistance dépend du répertoire $TITHON_HOME (par défaut ~/.tithon) qui doit être partagé entre le daemon et l’extension, condition remplie automatiquement via Remote‑SSH ou VS Code Tunnel. La journalisation en SQLite garantit la récupération rapide, mais la taille du journal peut croître indéfiniment si aucune rotation n’est appliquée, ce qui impose une gestion manuelle des archives. Enfin, le mécanisme de back‑pressure limite la mémoire du daemon en déconnectant les clients trop lents, mais cela peut entraîner des pertes de données temporaires pour ces clients.