Fwd: [pthreads] Changing cancellation type of another thread

[Borislav Trifonov <eimacdude at aol dot com>]

pthread_setcanceltype() can only act on the calling thread, so I am 
looking for an alternative to accomplish the following: I'm writing an 
application for kiosks and some of the threads are running third party 
code that is pretty much a black box to me. If any hang, by 
specification, the application must try to restart them rather than 
fail, and deferred cancellation sometimes doesn't happen and the 
subsequent join continues indefinitely. I considered running them in 
separate processes, but there is large amount of shared data protected 
by mostly lock-free synchronization, and the performance impact of 
moving to shmem between several processes was significant; also, much of 
the threading model is based on a task-stealing thread pool and changing 
that to a multi-process model is anything but straightforward. What I 
need is a way to try an asynchronous cancel if, after a synchronous one, 
the subsequent pthread_timedjoin_np() times out. The problem is the lack 
of way to change cancel types. Looking at the source for 
pthread_setcanceltype(), I was trying to see if I could make a version 
that takes a thread as a parameter instead of using THREAD_SELF and 
THREAD_GETMEM. The problem is if 
CANCEL_ENABLED_AND_CANCELED_AND_ASYNCHRONOUS (which has CANCELED_BITMASK 
as a dependent) is true, then the function calls __do_cancel() which 
calls __pthread_unwind() and that still uses THREAD_SELF, and I'm not 
brave enough to try to make modifications this far in the call chain. It 
looks like if I try a deferred cancel first, then CANCELED_BITMASK is 
set after the SIGCANCEL is sent to the thread. What happens if I then 
call a modified version of setcanceltype that makes the flag change to 
the target thread, but unlike the normal version which acts on the 
calling thread, I simply ignore the 
CANCEL_ENABLED_AND_CANCELED_AND_ASYNCHRONOUS situation and then try a 
pthread_cancel()? Will the stack fail to be unwound? That's an issue 
since due to heavy reliance on the RAII provided by C++ destructors in 
all parts of the application. Thanks