This is the mail archive of the pthreads-win32@sourceware.cygnus.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: asynchronous cancellation


On Mon, 15 Nov 1999, Bossom, John 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....
> 

[Most of C++ is out of scope for me so I've been hanging back
waiting for more informed comment, which John has provided, but I'm
still not clear about this issue.]

Is the last paragraph above meant as general advice or is it
specific to either the pthreads-win32 or Jason's implementation, or
both? I believe that the current pthreads-win32 method of using an
exception properly unwinds the stack. There are other problems with
the method though (apart from the lack of async cancelation), which
Jason has observed as explained later.

Looking at Jason's code: I'm assuming that scope is retained at the
point the thread is resumed (because stack pointers etc are
untouched). It isn't clear to me what happens when the thread exits.
Jason includes the statement "callDestructors(pSelf)". Is this
logical pseudo code for what needs to happen? Are destructors all
run properly in Jason's implementation, or can they be made to run
if not?


Back to the existing method of cancelation:
Jason points out in his README file (in his package) that the
current cancelation method using exceptions is prone to the
following problems (C++ exceptions of course):

void f() throw()
{
	/* Cancelation won't work in here */
	...
}

and:

try {
	...
}
catch (...) {
	/* This will catch any cancelation exception prematurely */
	...
}


My response to these is perhaps naive, but nevertheless could form a
reasonable solution, at least in part, if we persist with the
current method.

While both problems can be handled easily if the application
programmer knows the internal implementation of pthread-win32 (and
could therefore insert an appropriate catch block etc), we want
really to keep it opaque.

The following macro:

#define catch(E) \
	catch(Pthread_exception_cancel) { \
		throw(); \
	} \
	catch(E)

appears to work around the second case. Even though this can result
in redundant repetition of catch blocks for
Pthread_exception_cancel, this doesn't appear to be a problem for
the compiler (tested with g++).

The first case appears to be a little more difficult to provide a
workaround for. The following works for the empty list case (tested
only with gnu cpp/g++):

#define throw() throw(Pthread_exception_cancel)

but obviously not for the case where a list of exceptions is given.
It's a pity cpp can't differentiate between macros with empty and
non-empty arg lists.

Is there a more sophisticated way to do any of this? Is it worth
putting at least the "catch" macro into pthread.h? Is Jason's method
a better one (will require some remodelling of the existing cleanup
handler push/pop code)?

Ross

> 
> -----Original Message-----
> From: Jason Nye [mailto:jnye@nbnet.nb.ca]
> Sent: Friday, November 12, 1999 9:20 PM
> To: 'Pthreads-win32'
> Subject: asynchronous cancellation
> 
> 
> Hi, all
> 
> I've noticed a lot of you discussing asynchronous cancellation and
> mentioning how difficult it is to do under win32. I did some research
> and found a bullet-proof way of doing it (from a J. Richter example).
> Here is a sample of the code I used in my library:
> 
> If thread x wants to cancel thread y asynchronously, thread x should
> call cancelThread(y):
> 
> ----------------------------------------------------------------------------
> -----------------------
> 
> void cancelThread(HANDLE hThread)
> {
>     ::SuspendThread(hThread);
>     if (::WaitForSingleObject(hThread, 0) != WAIT_TIMEDOUT) {
>             // Ok, thread did not exit before we got to it.
>            CONTEXT context;
>            context.ContextFlags = CONTEXT_CONTROL;
>            ::GetThreadContext(hThread, &context);
>            // _x86 only!!!
>            context.Eip = (DWORD)AsyncCancelPoint;
>            ::SetThreadContext(hThread, &context);
>            ::ResumeThread(hThread);
>     }
> }
> 
> // declare AsyncCancelPoint:
> void AsyncCancelPoint()
> {
>     // pSelf is a pointer to a ThreadInfo (each thread has one --
> declared as __declspec(thread)).
>     popCancelCleanupHandlers(pSelf);
>     callDestructors(pSelf);
>     _endthreadex(PTHREAD_CANCELLED);
> }
> ----------------------------------------------------------------------------
> -----------------------
> 
> That is it. If a thread's cancel state is asynchronous and another
> thread requests that it be cancelled, the thread will suddenly find
> itself executing AsyncCancelPoint which is exactly what you want.
> 
> If you want to see it in action in my C++ library, go to
> http://www3.nbnet.nb.ca/jnye, follow the "current software projects"
> link and download the latest version of ObjectThread. You'll see how it
> fits into a complete library.
> 
> Hopefully this is useful,
> Jason
> 

+----------------------+---+
| Ross Johnson         |   | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra   | FAX:    +61 6 2015227
| PO Box 1                 |
| Belconnen  ACT    2616   | WWW:    http://willow.canberra.edu.au/~rpj/
| AUSTRALIA                |
+--------------------------+




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]