Subj : Re: Killing threads
To   : David Schwartz
From : Srini Palthepu
Date : Tue Aug 16 2005 06:28 pm


> 
>>I see. I was under the impression that, since I am sending the signal to
>>specific thread, they should go to the thread.
> 
> 
>     They do. But that doesn't change what they *do*. The receipt of a fatal 
> signal causes whatever received it to kill its process.


I understand now. Thanks for the explanation.

> 
>>My application has a set of daemon threads for doing the work
>>that are alocated for each client request. But when a thread hangs in
>>the proces of serving a client for any reason, I need to cleanup.
> 
> 
>     In general, you can't. If you lose a thread, you lose the process.


May be sometimes. but sometimes there may be cases where the thread is
not really lost, but need to be terminated/reset. Do I need
to giveup on the entire process for a problem in one thread?

>>I am trying to kill the hung thread and respawn a new one as a way
>>of cleaning up.
> 
> 
>     No good. What if it holds a mutex? You have to fix the problem.

I see the problem. How about cases where the thread does not hold any
mutex but just takes too long, or dependent on
some external events to complete its job. I need a sure way of
recovering if client times out.

>>I am using ACE toolkit thread framework that essentially
>>will be translated to Solaris thread sys calls at lowlevel.
> 
> 
>     How could a thread get hung? What can go wrong? If you really need 
> failure recovery, you need to use processes, not threads. With processes, 
> you can precisely control how they interact and recover from a failure, but 
> not with threads.

Time out is one possibility. The server thread actually forks new
process to do some work and depends upon external events that are
beyond the control of the server process. Hence we can not really
enumerate all possible reasons. But I am trying to see if I can
recover a thread that is taking too long for whatever reason.
Seperate process approach may be good but needs redoing  whole
lot of work. Not enough time for now.

thanks
srini

.