Re: Interrupting repl in Slime

Ah, you are right about them not being synchronized. The method on
LispThread is, though, which is how I got confused.
If you have a proposal for how to make things simpler and are interested in
getting it implemented, I'd encourage you to spec it out. I can see about
chipping in some effort.
Alan

On Mon, Apr 11, 2022 at 1:34 AM Alessio Stalla <[email protected]>
wrote:

> 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 <[email protected]>
> 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
>>
>>
>>