On tis, 2004-03-30 at 18:11, Arve Knudsen wrote: ... ... > > > I was thinking PTHREAD_CANCEL_ASYNCHRONOUS would be the option, but I > already rely on the default behaviour (deferred) for the regular cases, > where I politely ask the thread to exit. So I was thinking of some other > alternative. The older code I'm using as a reference, makes use of > pthread_kill. At first I thought the NPTL lib simply lacked this function > (not in pthread.h), but I see now its included through signal.h :p
There is another strategy though. Your thread will not get stuck without any good reason, right? So you can implement just enough logic so that your thread "knows" that it still has a chance to complete its task or else deallocate any resources held and return. The supervising thread you suggest will need some similar logic, so it is not about writing more code but rather moving the code to where the action is going on. Killing a thread from the outside is fairly simple. Keeping track of open files/malloc/whatever from the outside is a PITA. So go for autonomous threads. Your code will be easier to read and maintain, and therefore also more likely to be correct. /jens
