Joseph Ferano
e691512af3
The thunk calls flan_dev_result_begin before it evaluates anything, so an expression that signals is stopped inside the seqlock's window — and a restart taken from that break transfers past the thunk, so the matching end never runs. An unpaired begin cost nothing while the counter only moved at the end. It costs everything now: incrementing would leave the count odd for the life of the process, every later read reporting a write in progress, and C-x C-e dead until the program restarts. So begin sets the low bit rather than incrementing, and end clears it by setting rather than adding. The ordinary sequence is unchanged — 2k, 2k+1, 2k+2 — and an abandoned write is over as soon as the next evaluation starts. What that does not fix, because one buffer cannot: an evaluation running while another is stopped mid-render shares the buffer, so the inner value is the one that survives. That was true before the counter was a seqlock and is not a regression. Also noted in NEXT.md: rt_die in flan_rt.c has the same exit-with-the-loader- lock-held shape the break loop just lost. Not fixed with it, because rt_die is the non-dev path too, where there is no listener to deadlock against — whether it should be _exit always or only under --dev is a decision. And the 4K-cap assertions clamp their own String.sub, so a short body prints a failure instead of raising out of the test.