Interrupting repl in Slime

[Alan Ruttenberg]

I'm guessing that Thread.isInterrupted() was avoided because the check is
made inside every loop iteration. As a synchronized method I'm guessing it
might have been thought to hurt performance. A volatile read is cheap, as I
understand it. It's read from cache until a write invalidates a cache line,
at which point it becomes a slow read from memory.  Even the volatile check
is removed when compiling speed high and safety low. I haven't done
performance checks since it's the compiler that inserts the checks and I'd
rather not mess with the compiler unless I have to.

It's hard to say why the design is the way it is without someone who was
around when the compiler was written and understands the rationale chiming
in. While I learned enough to connect the two strands of interrupt
handling, I don't really understand the design choices. I wouldn't, without
further study, understand how to decide where it's appropriate to catch
InterruptedException, or where it's safe to handle interrupts. This work is
really a patch motivated by me wanting control-c to work more reliably.
It's a bonus that it improves interrupt-thread, and I only saw that I might
be able to do that towards the end. Similarly I thought I might have to
make some slime changes and it's nice that it worked out that I don't have
to. It was a relief that I didn't have to mess with the compiler, as that's
one more large chunk I don't have a good grasp of.

My main concern at this point is whether the changes introduce any
instability. I don't *think* so, but having others review the changes and
live with it for a bit would be good.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20220411/cab8a851/attachment.html>