Tensions in Practice: Prompt outer cancellation in tension with completing nested work¶
Nested job · child file inside a workspace
A job owns a workspace, and its child is still writing a file inside that workspace. A cancellation request targets the outer job. It cannot simply release the workspace beneath the live child. One policy interrupts and cleans up the child before releasing the parent; another defers the request until the child finishes normally.
Honor cancellation promptly
Begin discharging the outer job’s obligations when cancellation is requested.
Finish the current child unit
Allow already-started child work to reach its ordinary completion point.
Why these aims pull against each other
Both policies close the child before its parent. They differ in whether unfinished child work is abandoned through a supported unwind or allowed to finish while the parent resource remains held.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Unwind now
Deliver a supported cancellation to the child, execute its cleanup, then release the parent workspace.
- What it protects
- Begins freeing the parent without waiting for all intended child work.
- What it costs
- Unfinished child work is lost, and cancellation-safe cleanup must be implemented.
- When it fits
- Fits when the child supports interruption and its partial output can be discarded safely.
Illustration note: The example assumes cleanup succeeds. It does not promise instant cancellation or rollback of irreversible effects.
Finish child first
Let the current child complete and close its file; then release the workspace and start no further child.
- What it protects
- Preserves the current child’s completed result and ordinary cleanup path.
- What it costs
- The outer job and workspace remain active longer; a stuck child can delay cancellation indefinitely without another policy.
- When it fits
- Fits when the child is bounded or progress is monitored and preserving its work matters more than immediate release.
Illustration note: Deferral is an editorial implementation alternative that preserves the source’s nesting invariant.
What this illustration does—and does not—establish
Stack: Strict Ordering versus Out-of-Order Discharge (sign/direction) supplies the interior-release constraint; Stack: Normal Unwind versus Failure Unwind (temporal) supplies failure-path cleanup. Both authored policies preserve those constraints.
- The file really depends on the parent workspace; independent parallel jobs would not require this LIFO relation.
- Neither option closes an outer resource under a live dependent child.
- The arrows show obligation discharge, not compensating previously committed transactions or guaranteed recovery after process death.
Source entries
Stack
Stack: Strict Ordering versus Out-of-Order Discharge (sign/direction) supplies the conflict examined here.
Strict Ordering versus Out-of-Order Discharge (sign/direction)
LIFO forbids retrieving an interior item while items sit above it, but real systems sometimes must release a deep obligation early (cancel a parent, timeout an outer transaction). The competing concern is random-access or priority release.
Normal Unwind versus Failure Unwind (temporal)
The stack's behavior on orderly completion and on abnormal termination are different regimes: a clean pop versus an exception that must unwind through every pending level running cleanup.