Re: Interrupting repl in Slime

OK, I'll give it a shot as soon as I can.

On Mon, 11 Apr 2022 at 18:58, Alan Ruttenberg <[email protected]>
wrote:

> 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
>>>
>>>
>>>