From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Johnson To: "'Pthreads-win32'" Subject: RE: asynchronous cancellation Date: Tue, 16 Nov 1999 01:30:00 -0000 Message-id: References: <450FB96A8F51D31186CD00805F95C7DC9C3506@SOTTEXCH62A> X-SW-Source: 1999/msg00132.html 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 | +--------------------------+