Re: asynchronous cancellation

[Jason Nye <jnye at nbnet dot nb dot ca>]

John Bossom wrote:

> > Interesting solution...
> >
> > To work with the pthreads-win32 library, your AsyncCancelPoint
> > needs to get pSelf from dynamically declared TLS... (i.e. pthread_self,
> > or it's internal implementation).
> >
> > Just a note to C++ users: one shouldn't use the built-in pthreads
> > cancellation if they expect C++ stack unwinding to work....
> >

I'm a C++ developer, not necessarily a guru in the ways of pthreads -- I
do know some its specifications, however -- please, no flames!

Why does the stack have to be unwound when a thread is cancelled? Is
this a requirement of pthreads (I'm pretty sure this is not the case) or
is it just the way that pthreads-win32 has always implemented it and you
are sticking to this design? My ObjectThread library does not unwind the
stack when a thread is cancelled and the net result is that it has no
weird implementation-specific side effects from using exception handling
(whether SEH or C++) and there is no unnecessary performance overhead
when a thread gets cancelled -- no unwinding the stack, just executing
cleanup handlers/destructors and calling _exitthreadex().

IMHO using SEH and C++ exceptions ties pthreads-win32 to specific
compilers/languages and introduces unnecessary implementation-specific
side-effects that will catch some developers by surprise (it caught me
by surprise -- and note John's last point). Cancellation can be easily
implemented without using such constructs and the result is a
compiler-independent library in which cancellation acts as one would
expect.

Note that I'm not trying to say "Mine is better than yours", I'm just
saying that there is an another way to achieve cancellation that may be
more reliable and more compliant to the standard.

Cheerio,
Jason