Child Exit Wake-up

How the loop that runs our children should learn that a child has ended, and what to do now about a defect found on the way. Asked for in your message of 2026-11-01 (13:41): the handler's design “has been a very important decision and its facets should have been discussed in detail”.

Words used throughout. The executor: ShellSpawn, the module that runs ShellSubset parse trees through posix_spawn (claude/pspawn-design.md). The loop: its one place that waits, in select, for children to end and for pipes that Perl itself reads. A reaction: what is to happen when a child has ended (start the next command, set $?, …). An immediate signal handler runs inside the signal, in the middle of whatever Perl is doing; a deferred one runs later, between two Perl operations. The findings S1–S7, C1–C4, I1–I3 are in claude/perl-signals-findings.md.

✓ Go: do it as planned. ✗ No-go: don’t; do what “If No-go” says. ◆ Discuss strategy first: settle the approach first; holds back only the items that depend on it. ? Explain first: a show-stopper; I explain before doing anything else. ? Explain later: I explain after doing the rest. Unmarked: not done this round, left for later; it is not a rejection. A note that settles an item (picks an option, states the rule, or says the plan is right) counts as Go even without the button. My answers carry a tag: No reply needed, Your turn (I asked you something), or Answered, Claude hasn’t read it yet. The “Your turn” filter shows the items waiting for you.

What Go means Mark and wait: I implement only when you tell me in chat. Implement when there are no show-stoppers: “Explain first” items block everything; “Discuss” items block only what depends on them. Implement what’s independent: Go items that don’t depend on an open item; I list the ones held back.

Loading marks…

Filters