[concurrency-interest] Does "Thread.stop" do what is says it does?

Miles Sabin miles at milessabin.com
Thu Aug 4 15:40:58 EDT 2005

Dawid Kurzyniec wrote,
> Sometimes, though, "friend" services are allowed to break the
> isolation barriers and share data, so the "Isolates" API is not
> applicable. Instead, we implement sandboxing via separate class
> loaders, strict confinement, and security policies.

I'm not going to comment on the ethics of using Thread.stop, but I can't 
let this pass ...

Isolates really, really, really are exactly what you want. Yes, you'll 
most likely have to use message passing to achieve effects equivalent 
to shared state. But this will always be possible, and assuming a 
reasonably well behaved and efficient implementation of the Link API a 
message passing alternative shouldn't be problematic from a performance 
point of view.

Sandboxing via classloader partitioning and security policies are the 
best we currently have, but they can't prevent interference due to 
buggy or malicious code, and they can't provide resource managment or 
revocation in any particularly general or reliable way ... Thread.stop 
is just the tip of the iceberg.

"Partial isolation" would be lovely, but to do it properly (or even 
approximate it) would require so many drastic changes to Java's type 
system and overall semantics that I'm sorry to say we'll never see it.



More information about the Concurrency-interest mailing list