It seems 2.13 alsocallsThread.currentThread.interrupt(), should that be done here too?

#6610 says "Makes Futures correctly handle Thread.interrupt", I don't know what that entails.

The newextended example shows receiving the ExecutionException; on 2.12 it currently throws up the stack; with this fix, the world is right again. I just waffled on whether to re-interrupt inthis fix for vulpix whereprocess.waitFor is interrupted bypool.shutdown. It should interrupt (after retrying its work) in case subsequent work happens on the worker thread, even though one might assume that one is the last "client" of the thread. So I'd vote for interrupting the current (worker) thread.

I've forgotten the brouhaha over running side effects on the "current" thread; is there such an executor? But maybe it is irrelevant whether we know who created the current thread. If we caught the exception, we should set the interrupt status.

I don't really understand that part and it's not obvious how to adapt it to the 2.12 design which is completely different. Since the new test suite passes with this version, it's obviously untested (and unspecified). Is the idea to always interrupt the current thread if a Promise was completed with a boxed InterruptedException?

Is the idea to always interrupt the current thread if a Promise was completed with a boxed InterruptedException?

That's how the 2.13 code reads.

Googlin' I find many places that say "if you catch anInterruptedException, you should callThread.currentThread.interrupt()"

• https://stackoverflow.com/questions/20934817/why-thread-currentthread-interrupt-be-called
• https://stackoverflow.com/questions/4906799/why-invoke-thread-currentthread-interrupt-in-a-catch-interruptexception-block
• https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html

summon[@viktorklang]?

Updated to add the same interrupt handling as in 2.13 (i.e. not always interrupting whenInterruptedException was caught but only when the promise was successfully completed with this exception).