
Java’s Mysterious Interrupt - mattiemass
https://carlmastrangelo.com/blog/javas-mysterious-interrupt
======
amarkov
For an embarrassing amount of time, I didn't even realize Java interrupt()
could only interrupt blocking operations. I guess I thought they were like
hardware interrupts, capable of just showing up anywhere without the program's
cooperation.

~~~
AndrewBissell
Way back in the day this used to exist in Thread.stop(), which would kill
threads in a hilariously indiscriminate manner. Long since deprecated:
[https://docs.oracle.com/javase/8/docs/technotes/guides/concu...](https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html)

~~~
derefr
It's strange to deprecate something when you still can get exactly the same
behavior by grabbing the thread's PID and then shelling out with a `kill -9`.

~~~
lomnakkus
How do you get a thread's PID in Java/on the JVM?

Regardless, the deprecation serves as prominent warning that the programmer is
about to shoot themselves in the foot.

(I'm actually more surprised that stop() hasn't been removed after all this
time.)

~~~
smarks
There are narrow and unsafe uses of the no-arg Thread.stop() overload so it
remains in the platform, although deprecated. There is an overload
Thread.stop(Throwable) that is deprecated “for removal”. It’s been a no-op for
several releases and the API will eventually be removed entirely.

------
Animats
It's more like thread cancellation than an interrupt.

Few languages do cancellation well. Either it doesn't work right, or it does
something overly elaborate like LISP breaks.

~~~
evincarofautumn
I actually like the way it is (or can be) done in Haskell: since polling an
“interrupted” status would be a side effect, instead they turn the problem on
its head: you can throw an _async_ exception _to_ the task you want to
interrupt, given its ID, and it behaves essentially as if the code it was just
executing has thrown a synchronous exception.

Sounds spooky, and it does require writing code in an exception-safe way, but
that’s generally easy: pure code is largely exception-safe by nature, and
impure code can use “bracket” (“finally”, “mask”, “ResourceT”, &c.) to acquire
& release resources—and should already be using these functions anyway to
handle regular synchronous exceptions. Async exceptions are _very_ useful for
killing a task that’s using too much time/memory, or initiating a graceful
shutdown.

------
lenkite
Making InterruptedException a _checked_ exception was a _mind-boggling_ stupid
design mistake that should have been immediately corrected but unfortunately
never was. I always wince when writing scalable, long-running concurrent Java
code. You need to interrupt and handle interrupts when tasks are hung, but you
then need either litter up all your Java interfaces or do lots of exception
detection juggling.

~~~
kovrik
Well, nowadays all checked exceptions are considered to be a mistake.

~~~
i386
It’s explicit and encourages the consumer to handle errors correctly. The
negatives seem to be cosmentic arguments.

~~~
Salgat
Forcing the programmer to add handlers for exceptions he may not even want to
handle (sometimes it's okay to pass it up the call stack) just creates a mess
in the source code. It's fine as a suppressible compiler warning, but not as a
compiler error.

~~~
kuschku
Well, in modern languages, the same concepts are all coming back.

Go has its product types for errors, and Rust uses sum types.

As result you end up with basically the same code as with exceptions, just
even more verbose.

------
anameaname
As another surprising thing, calling interrupted() actually clears the
interrupted bit. If it's true, you pretty much have to throw
InterruptedException. Otherwise, you have to re set the bit, and exit quietly.

~~~
kevinconaway
> calling isInterrupted() actually clears the interrupted bit.

Thats incorrect. Calling Thread#interrupted[0] clears the interrupt status and
returns true if the current thread was interrupted. Thread#isInterrupted()[1]
only returns the value of the interrupt status on the thread receiving the
method call. The interrupt status is unaffected by that method call.

[0]
[https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.h...](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#interrupted--)

[1]
[https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.h...](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#isInterrupted--)

~~~
anameaname
You are right, editted.

~~~
crunchlibrarian
As the article itself says, you're unlikely to write correct code if you use
these language features. :)

