<div dir="ltr"><div>Ah, you are right about them not being synchronized. The method on LispThread is, though, which is how I got confused.</div><div>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.</div><div>Alan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 11, 2022 at 1:34 AM Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Apr 2022 at 07:25, Alan Ruttenberg <<a href="mailto:alanruttenberg@gmail.com" target="_blank">alanruttenberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>Alan<br></div><div><br></div><div><br></div></div>
</blockquote></div>
</blockquote></div>