#5614 handling of interrupts

[Gunter Königsmann]

one thing I believe to have learned from the threading work is: might it be that if maxima gets a interrupt signal during internal bookkeeping (for example during the wrong part of an assume) that can leave it in a broken state?
Background: Our lisps declare critical sections as "atomic. don't interrupt".

[David Scherfgen]

I asked Claude to investigate.

Verdict: Yes. Ctrl+C can leave Maxima in an inconsistent state. I reproduced it on SBCL 2.6.9 with real SIGINTs: 12% of interrupts during a loop of function calls and 3% during an assume/forget loop left corrupted state. Ordinary computations should be hit less often, but I did not measure that. The cause is that the interrupt unwinds asynchronously at any instruction; Maxima has no interrupt masking, and multi-step updates are not rolled back.

What can go wrong:

• Leaked variable values: variables bound by a function call, block or ev keep the local value (e.g. a = 1 instead of 100). This includes option variables, so simp:false or a changed fpprec can stay set globally.
• Inconsistent facts: a fact can stay in effect but be missing from facts(). It can also be listed in facts() but not in effect, in which case forget answers redundant.
• Phantom function: functions can list a function that has no definition.
• Wrong bigfloat digits: the fpprec option can disagree with the internal precision, so bfloat returns the wrong number of digits.
• Stale binding stacks: the internal bindlist/mspeclist stacks keep stale entries, or the local values are never restored.

Recovery: kill(all), forget or re-assigning fpprec repairs the facts and precision cases. Leaked variable values stay until reassigned. If the session matters after an interrupt, restart it.