Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed1.swip.net!news.astraweb.com!border5.a.newsrouter.astraweb.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 02 Aug 2013 12:51:29 -0500 From: "Chris Uppal" Newsgroups: comp.lang.java.programmer References: <8fe57dc2-a323-4821-941c-4036663cbce5@googlegroups.com> Subject: Re: What is so bad aboud Thread.stop() ? Date: Fri, 2 Aug 2013 18:50:02 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Message-ID: Lines: 32 X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-qAD35aYJAjl76yu368EVyRK862aQjJj5n+/xdj1nj/9JXt9p+WxeoL9xrQ0FMaeHannb/EMEzmMSg/L!xVQ8DyvUh2Mg3LZYxBJ+JXmb+VCkNKmXxqkWwhpdKvN/+NGR/PcYKhfyECJNShUxiB39kKIpCA== X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2868 Xref: csiph.com comp.lang.java.programmer:24880 taqmcg@gmail.com wrote: > The use of Thread.stop() is strongly deprecated, but I'm a bit confused > by the explanation given in the documentation: (e.g., >[...] > So what is the big hullaballoo about? I suspect (modulo my other suspicion that you can't rely on exactly what Thread.stop() actually does in an actual implementation) that /if/ there is no mutable state shared with the rest of the program, then it might be OK. Problem is: there's not a lot of point in a thread that shares /no/ state with the rest of the program. If it's doing some computation (your? example of an untrusted regexp engine for instance) then it has to get the answer back to the calling thread somehow, and that is problematic. Maybe there are some simple (in the sense of unsophisticated) mechanisms -- the calling thread polling a volatile variable perhaps (though I have doubts about the semantics of that: does reading a volatile variable guarantee that the data /referenced/ by that variable are consistent ? My reading of the JLS doesn't find an answer to that question). But, say, stop()-ing a thread that is writing to a shared queue is a no-no. /If/ you know that the thread is in a fixed, stable, state then you can probably kill it (assuming the state is suitable), but what about the end-points -- just as it is entering or leaving that state. I find it difficult to imagine how you could be sure, avoiding race conditions, that it would be safe to stop() the thread unless your architecture was already such that implementing an alternative method wouldn't be easier (or at least, no harder -- and easier to justify to your peers ;-) -- chris