Subj : Re: Killing threads To : comp.programming.threads From : David Schwartz Date : Tue Aug 16 2005 03:57 pm "Srini Palthepu" wrote in message news:43026253.7030008@Lucent.com... > Thanks for the mail. >>>I am having trouble selectively killing threads. >>>When I send SIGKILL or SIGTERM to a thread >>>I end up killing the whole process. >> Yup, that's what the default signal handlers for those signals do. > 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. >>>Is there something I am overlooking? >>>Is there a standard idiom for doing this kind >>>of thing? >> Why are you trying to kill threads? Is cancellation not what you want? >> If not, you need to roll your own signalling mechanism. >> Without knowing much more about your application structure, I can't >> offer better suggestions except to say that it's a thoroughly solved >> problem. > 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. > 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 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. DS .