Re: Continuously re-spawning a stopped/killed thread

David Holmes via Concurrency-interest <[email protected]> Fri, 18 Dec 2020 21:34:38 +1000
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <[email protected]>
Catching ThreadDeath is the “easy” part. But if random threads are calling Thread.stop on your thread at unknown timers then whatever your thread is trying to do can be left in a corrupt and potentially unrecoverable state. If another part of the application calls Thread.stop on your library thread then that is their stupidity – why should you care? Libraries can’t be expected to deal with a hostile environment.

 

Cheers,

David

 

From: Concurrency-interest <[email protected]> On Behalf Of Volkan Yazici via Concurrency-interest
Sent: Friday, 18 December 2020 9:05 PM
To: [email protected]
Subject: Re: [concurrency-interest] Continuously re-spawning a stopped/killed thread

 

[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

In a nutshell, we have a wrapper running in the background that calls Log4j Layouts to render LogEvents. 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