Interrupting repl in Slime

[Alessio Stalla]

I'm talking about Thread.interrupted(), which also resets the flag, not
isInterrupted(); anyway, neither of those is a synchronized method. I think
this part of ABCL should be made simpler, it would also be easier to reason
about it then. Also, Java code invoking Lisp code won't necessarily know
about ABCL's thread interrupt protocol, and ABCL's threads may look like
they don't play nice with interrupts.

On Mon, 11 Apr 2022 at 07:25, Alan Ruttenberg <alanruttenberg at gmail.com>
wrote:

> 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/6860b54f/attachment.html>