Colleagues at Google expected that a ForkJoinPool would clear the interrupt status before executing a task, in part because ThreadPoolExecutor does so. A leak of interrupt status to an unrelated task that happens to be next to execute in the same pool thread can be disastrous.

This raises a number of thorny design issues around Future.cancel(true) which may be implemented via Thread.interrupt.

The interrupt status is a single bit with no indication of its origin or meaning, so it's not surprising its handling is murky. Unix signals are a similar mechanism that do contain auxiliary information (siginfo).

Both FutureTask and Guava Futures are prone to leak interrupt status to their environment (typically inside an executor) when they are cancelled. Which is a problem when that environment is not prepared for that interrupt. Not all executors isolate tasks from each other by clearing interrupt status. In general it's impossible to ensure this. FutureTask implements Runnable and so can simply be run() in any thread or executed inside any Executor. None of the documentation makes the problem clear - e.g. FutureTask does not document its interrupt handling.

ForkJoinPool does hint that it's """An ExecutorService for running ForkJoinTasks""" and ForkJoinTasks don't interrupt on cancel but the spec doesn't actually say that tasks should not leak interrupts. The situation for ForkJoinTasks is complicated by the fact that they might be run by non-pool threads that "help" while waiting to join a task.

ForkJoinPool threads do end up clearing interrupt status - whenever they park - if they didn't, they would infloop calling park. The fact that the pool threads themselves end up defending their own management code against interrupts leaked from task execution suggests they should also defend other user tasks.

Maybe the Loom project will have better task isolation by having the interrupt status belong to a fiber instead of a thread.

Maybe the Loom project should rethink the problem of task interruption/cancellation. Structured concurrency folk have tried to tackle the cancellation problem in other languages.