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