Re: Continuously re-spawning a stopped/killed thread

Hi,

On 12/18/20 1:15 PM, Volkan Yazıcı via Concurrency-interest wrote:
> I want to return back to the first simple form where I only catch 
> Exceptions, but then I need to get the thread automatically respawned 
> on unintended deaths. I thought of leveraging the "unhandled exception 
> handler" mechanism of Executors for this automatic respawning. What do 
> you think?


Well, the only difference between recovering from Error(s) in the same 
thread and letting the thread die and spawning another thread to 
continue with processing is in ThreadLocal variables. If you continue 
processing in existing thread you keep them, if you spawn another 
thread, you start fresh.

In both occasions the shared state (heap objects reachable from old/new 
thread) is the one that might get corrupted when a thread throws 
ThreadDeath as a result of another thread calling Thread.stop() on it. 
The only way to avoid such corruption is for all code executing in such 
thread to very carefully perform modifications to state that would still 
be reachable to the thread after it recovers from ThreadDeath (or to 
another thread). Each modification (assignment) must leave behind 
reachable state that is valid. This is very hard to achieve if you use 
common data structures that are not designed with that in mind, let 
alone code that you don't control executing in that thread. 
Theoretically it is doable, but nobody does that.

So I would say that if you refrain from calling Thread.stop() in your 
code, you've done your part. If anybody else is using your code and 
calls Thread.stop() in their code, it is their problem, not yours.


Regards, Peter




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