Joseph Ferano
fe1237ccea
Found by a concurrency audit that demonstrated three of them against a running program rather than reasoning about them. The break state was a flag, not a depth. A C-x C-e thunk may itself error, and the break loop that catches it nests inside the first - so the inner loop's resume stored broken = 0 while the outer one was still stopped. Every verb that could rescue the program then answered "not stopped", status answered "running", and the outer loop spun forever with no protocol path out. Only kill recovered it, and Emacs' modeline read live throughout. The audit showed it with ticks frozen at 0 beside :stopped nil. It is a depth now, capped, and past the cap the program says so and exits rather than grinding. The condition name is saved and restored per frame for the same reason. An idle connection wedged the whole listener. The accept loop is single-threaded and serves each connection inline on a blocking read, so a client that connected and sent nothing - an editor killed mid-request - blocked every later request including the abort that ends a stopped program. Worse, requests the client had already given up on were served when its socket finally closed, so an abandoned abort could kill the program minutes later against a state that had moved on. Two seconds is generous for one line. chosen_ready was cleared after the resume attempt, so a restart arriving in that window was answered ok and then erased. It is claimed into a local and cleared first now, which also keeps strlen off a buffer the listener may be writing. And aborting was sticky: an abort that passed its check just as the program resumed stayed armed and would have killed it at the next unhandled error, minutes later, in unrelated code, giving nobody the chance to choose.
