Gestion d'EINTR : réessayer l'opération spécifique sans renouveler tout son délai

Ce que c'est

La documentation des signaux Linux explique qu'une interface bloquante interrompue peut redémarrer automatiquement ou échouer avec EINTR, selon l'interface et SA_RESTART. Certaines opérations ayant déjà transféré des données rapportent une progression à la place. Le comportement documenté est spécifique à chaque interface, donc « réessayer chaque appel système en échec » n'est pas un enrobage général valable. Manuel des signaux Linux

Pourquoi c'est important

Un agent peut gérer l'interruption en réexécutant toute l'opération avec un nouveau délai. Un flux de signaux peut alors maintenir un travail en vie au-delà de son budget prévu. Séparer la tentative d'appel système de l'opération applicative, et préserver la progression, le délai et l'état d'annulation de cette dernière.

Comment l'appliquer

• Lire le manuel pour l'interface exacte et la plateforme cible. Consigner si elle peut renvoyer EINTR, redémarrer automatiquement ou rapporter une progression partielle pour le descripteur et les réglages concernés.
• Traiter la progression positive avant d'envisager de réessayer sur erreur. Conserver l'état d'entrée ou de sortie restant au lieu de redémarrer une opération à plusieurs étapes depuis son début.
• Représenter le délai applicatif par une échéance fixe et recalculer l'attente restante avant chaque nouvelle tentative éligible. Vérifier la condition d'annulation avant de réessayer.
• Éviter les macros larges qui réessaient des opérations non liées sans tenir compte de leur sémantique particulière. Garder les exceptions visibles et justifiées dans l'implémentation de l'enrobage.
• Proposer des tests contrôlés délivrant un signal pendant l'opération bloquée, avec et sans la politique de redémarrage concernée. Vérifier l'achèvement borné et la comptabilisation correcte de la progression partielle.

Pièges

Les règles de redémarrage diffèrent selon les systèmes Unix et selon les interfaces d'un même système. Les environnements d'exécution de langages de haut niveau peuvent aussi envelopper les appels système, donc examiner cette couche avant de dupliquer son comportement. Un montage de test à signal synthétique ne peut prouver tous les calendriers d'interruption possibles. Cet article propose une revue et une stratégie de test ciblées ; il ne revendique l'exécution d'aucune expérience sur les signaux, ni que tous les cas d'EINTR devraient être cachés aux appelants.