Interruption, backpressure and bounded attempts

What this concept is

A retry policy classifies conditions and defines a stopping rule. The lab retries only a callback result of -1 with EINTR, counts all calls, and stops on zero progress, permanent errors, EAGAIN or exhaustion.

Why it matters here

A loop that retries every error can consume CPU indefinitely. A loop that treats an interrupted no-progress call as success silently loses output. Counting attempts makes the finite teaching policy testable.

Concrete example

With budget 3, the sequence EINTR, accept 2, EINTR stops with two bytes accepted and budget exhausted if more input remains. With a blocking callback, even the first attempt can take arbitrarily long. The budget is a call-count bound, not a deadline.

Common confusion / misconception

EAGAIN is not an instruction to spin. A later event-driven design needs readiness waiting and a deadline/cancellation policy. A positive short write is progress, not an errno failure; stale errno after success is irrelevant.

How to use it

Capture errno immediately after a negative return. Keep byte offset unchanged for EINTR. Terminate on zero progress with a distinct status. Record the number of attempts and exercise repeated interruption, exhausted budget and partial progress independently. Do not hide unavailable platform behavior behind a fake claim of real-system coverage.

Check yourself

Why does a zero-byte result need an explicit policy? Can a callback-count budget bound wall time? Which tests distinguish interruption from nonblocking backpressure?

Mini drill or application

Use budgets 0, 1 and 2 on a four-byte input with two-byte chunks. Predict complete versus exhausted results and the accepted prefix. Add repeated EINTR without changing the input offset.

Read this only if stuck

The C Programming Language for syscall error handling and the lab header for this exercise’s policy. Read the relevant platform manual before applying it to a production descriptor.