[concurrency-interest] Hung progress in ThreadPoolExecutor ExecutorCompletionService when slave threads killed.

Dawid Weiss dawid.weiss at gmail.com
Mon May 14 04:39:44 EDT 2012

> because of stop(). But at least there we don't attempt to reuse any objects that were in use by the threads that got killed. I confess I'm not completely clear on your Executor usage here.

If I had full control over the tested code then this wouldn't be a
problem (because I'd react to interrupt properly and shut down the
executor). The code I'm using Thread.stop() for is much like junit --
it's a test runner so it executes arbitrary code (it has no control or
knowledge of).

Like I said, it probably could be solved by weaving stuff into that
code at runtime, I just looked for something that woud avoid this. In
99% of the cases code should react properly to Thread.interrupt, the
rest is, well, badly written tests.

> Generally Thread.stop does far more damage than incidental non-malicious threads; and malicious threads can just ignore any exception you throw at them via Thread.stop.

I agree. With a test framework left over background threads can affect
other tests further down the execution path and this isn't nice
because it makes debugging really hard (failing test passes in
isolation). I thought of a few alternatives, the "safe" side of the
spectrum is to just detect thread leaks and simply ignore any tests
after that (with an appropriate message). It's a treadeoff, as always.

> Aside: for a while now there's been some background thought on how to fix this for the more common cases of StackOverflowError and possibly OutOfMemoryError. Handling OOME is a somewhat more tractable problem at least in lower-level library code. StackOverflowError is rather nasty and will probably need some VM assistance.

Ugh. Didn't even think of that. Nasty.


More information about the Concurrency-interest mailing list