Re: Continuously re-spawning a stopped/killed thread

Hello,

ThreadDeath is part of the Thread#stop  mechanism. This whole concept 
has been deprecated for over 10 Years or so. If you "need"/"want" to 
implement according to the deprecated/broken Thread#stop specification : 
Yes you need to add a special catch Handler for ThreadDeath.

However this doesn't really make the world a much better place. Why 
would a user call Thread.stop? To shutdown your service. But you already 
have implemented a better shutdown mechanism, as has been described in 
the Thread.stop javadoc:

  Many uses of stop should be replaced by code that simply modifies some 
variable to indicate that the target thread should stop running. The 
target thread should check this variable regularly, and return from its 
run method in an orderly fashion if the variable indicates that it is to 
stop running.

So adding a ThreadDeathHandler only does something if somebody is using 
the API wrong in the first place, and it's not really clear if that 
something is good.

Best Regards,

Thorsten


Am 18/12/2020 um 12:05 schrieb Volkan Yazıcı via Concurrency-interest:
> /[Today while checking the mailing-list archives to share the link of 
> my question with a friend, I noticed Martin Buchholz's response, which 
> I could find neither in my inbox, nor in spam folders. Maybe missed 
> during the recent Google outage?]/
>
> On Tue Dec 15 15:44:21 EST 2020 Martin Buchholz wrote:
> > Why not just try { ... } catch (...) { handle ... } in your thread's 
> main method?
>
> That is what I had in mind initially:
>
> try { delegate(); }
> catch (ThreadDeath ...) { ... }
> catch (Throwable ...) { ... }
>
> But is this it? These sort of blacklists always make me nervous. I did 
> not know about ThreadDeath until a user complaint. Maybe there are 
> more such corner cases that I need to prevent against, hence my 
> question to this list.
>
>
> On Mon, Dec 14, 2020 at 11:24 AM Volkan Yazıcı 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Hello,
>
>     In Log4j, we need to run a background task and keep it alive —
>     unless JVM is stopped or our *while (!stopped)* condition fails
>     after an interrupt. That is, if the task fails for some reason
>     (e.g., by means of throwing an exception, interruption, or
>     *ThreadDeath* due to *Thread#stop()*), it needs to be re-spawned.
>     What is the most robust/decent way to implement this?
>
>     For the records, this is the problem I am dealing with in Log4j:
>     https://github.com/apache/logging-log4j2/commit/56436ad2176eac000d2821690e4373f097b76670#r44892412
>     <https://github.com/apache/logging-log4j2/commit/56436ad2176eac000d2821690e4373f097b76670#r44892412>
>
>     In a nutshell, we have a wrapper running in the background that
>     calls Log4j *Layout*s to render *LogEvent*s. Though certain
>     layouts can do really strange things from calling
>     *Thread.currentThread().stop()* to throwing an *Error*. These
>     cause the wrapper thread to get killed.
>
>     I have found work arounds using uncaught exception handlers
>     <https://howtodoinjava.com/java/multi-threading/restart-thread-uncaughtexceptionhandler/>,
>     though I couldn't be sure if this is the right way to do it.
>
>     Kind regards.
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest