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

√iktor Ҡlang viktor.klang at gmail.com
Mon May 14 04:47:36 EDT 2012


On Mon, May 14, 2012 at 10:39 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:

> > 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.
>

It was a horrible mistake to make all Throwables Catchable.


>
> Ugh. Didn't even think of that. Nasty.
>
> Dawid
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120514/7c15871a/attachment.html>


More information about the Concurrency-interest mailing list