Écritures partielles : avancer le décalage du tampon plutôt que renvoyer la charge utile entière

Ce que c'est

Le manuel Linux de write indique qu'un appel réussi peut transférer moins d'octets que demandé. Sa valeur de retour indique à l'appelant la progression réalisée, et un appel ultérieur peut en transférer davantage ou échouer. Un succès n'implique donc pas que la totalité du tampon applicatif a été consommée, ni qu'un stockage durable a été établi. Manuel Linux de write

Pourquoi c'est important

Un agent peut retenter d'envoyer le tampon d'origine après une écriture courte, dupliquant ainsi le préfixe déjà envoyé. L'état déterminant est le suffixe non envoyé. Il faut rendre cet état explicite à travers la progression ordinaire, l'interruption, la contre-pression et l'échec définitif, plutôt que de traduire tous ces cas en une nouvelle tentative générique.

Comment l'appliquer

• Suivre le décalage courant et le nombre total d'octets prévu. Lors d'un retour positif, avancer d'exactement la quantité rapportée et ne présenter que le suffixe restant lors de l'appel suivant.
• Distinguer une erreur définitive d'un résultat « bloquerait » (would-block) sur un descripteur non bloquant. Préserver le tampon en attente et reprendre via le mécanisme de disponibilité choisi plutôt que de boucler activement (busy-loop).
• Définir une politique explicite pour une progression nulle, afin qu'une boucle ne puisse pas tourner indéfiniment. Garder les échéances et l'annulation observables tant que la sortie reste en attente.
• Proposer un dispositif d'écriture contrôlé qui n'accepte qu'une partie de chaque tampon, puis injecte de la contre-pression ou un échec. Vérifier la séquence d'octets résultante exacte, pas seulement le nombre d'appels.
• Pour un protocole de plus haut niveau, définir ce que signifie un message partiellement transmis après un échec. Ne pas le rejouer automatiquement sur une nouvelle connexion sans la règle de reprise propre à ce protocole.

Pièges

Une boucle d'écriture résout la comptabilité locale des octets, pas la livraison applicative garantie exactement une fois. La durabilité du fichier et l'accusé de réception du pair sont des contrats distincts. Vérifier aussi comment l'application gère un tube (pipe) ou un socket fermé, y compris le comportement des signaux concernés. Aucune exécution d'injection de fautes sur les appels système n'est revendiquée ici ; le dispositif est une conception de régression proposée pour l'enveloppe (wrapper) en cours de modification.