31 Mar
2004
31 Mar
'04
6:06 a.m.
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