Subj : Re: Killing threads
To   : comp.programming.threads
From : David Schwartz
Date : Tue Aug 16 2005 05:32 pm


"Srini Palthepu" <psrini@Lucent.com> wrote in message 
news:43026878.4020400@Lucent.com...

>>>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?

    Yes, you do. If you don't know exactly what the problem is, the process 
is lost. If you do know exactly what the problem is and have a sane way to 
clean it up, that's another story. Threads share everything, including 
problems.

>>>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.

    Sure, with the cooperation of the thread, you can time it out any way 
you want. But the thread's code has to fully cooperate with you.

>>>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.

    You can't recover a thread that is taking too long for "whatever 
reason". You must address each reason individually.

    DS

.