<div dir="ltr"><div>The functions that ABCL uses in Threads.java are thread.interrupt and thread.isInterrupted. It overrides interrupt and isInterrupted to implement interrupt-thread - by saving away the function the target thread is to be interrupted with.  Remember, interrupt-thread isn't executed by the thread to be interrupted, it's called from another thread. The receiving thread handles InterruptedException, which is only called on explicit check of interrupt state or from sleep or wait.<br></div><div><br></div><div>Separately, in Lisp.Java there's setInterrupted and handleInterrupt that don't use the java mechanism. Rather setInterrupted sets a static volatile  Lisp.interrupted, handleInterrupted clears the variable and calls break. setInterrupted, as I said, is only called from interrupt-lisp. Code generation inserts checks of Lisp.interrupted and calls handleInterrupted if it is set. I have a feeling that this part was done so that frequent interrupt checks could be made without taking the performance hit of a synchronized method call. Remember this check is done inside every loop iteration. The check for Lisp.interrupted is a volatile read, which in most cases is handled in the cache. A write to the volatile invalidates the cache forcing the new value to be read from memory. So much less expensive.<br></div><div><br></div><div>It would be useful to know the history of how it came to be that there are two different interrupt mechanisms.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 7, 2022 at 7:21 AM Alessio Stalla <<a href="mailto:alessiostalla@gmail.com" target="_blank">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"><div>No, I mean <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#interrupted--" target="_blank">https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#interrupted--</a></div><div><br></div><div>The only deprecated methods are suspend, resume and stop. The interrupt machinery is what developers are supposed to use (at least when not using some higher-level framework). It's a form of cooperative multitasking, since a thread can completely ignore the interrupt. However, given we have control over Lisp threads, we can play nice with that convention, and maybe offer a without-interrupts special form for performance-critical code where the developer assumes the responsibility of checking for interrupts in selected moments.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 7 Apr 2022 at 11:42, Mark Evenson <<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.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"><br>
<br>
> On Apr 7, 2022, at 08:22, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>> wrote:<br>
> <br>
> […] Java threads already natively have an interrupt flag. <br>
<br>
Presumably, the [Thread.State enumeration] is what you are referring to. I have checked that it is present in openjdk{8,11,17}, and not marked as deprecated.<br>
<br>
[1]: <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.State.html" rel="noreferrer" target="_blank">https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.State.html</a><br>
<br>
-- <br>
"A screaming comes across the sky.  It has happened before but there is nothing <br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>