[Openthreads-info] Re: [osg-news] Win32 Thread Yield

[Don H. <ha...@pl...>]

On Tue, Aug 19, 2003 at 06:35:07PM -0500, Sean Spicer wrote:
> 
> Hi Robert,
> 
> On Tuesday, August 19, 2003, at 04:38 PM, Robert Osfield wrote:
> 
> > Hi Sean,
> >
> > It occurs to me that it be would be ideal if the code which is calling 
> > a
> > cancel() blocks on the successful completion of the cancel.  For 
> > instance in
> > a Procucer we want to prevent the desctruction of any objects to after 
> > the
> > threads themeselves have been cancelled, otherwise we risk deleting 
> > data that
> > is still be accessed by the running thread.
> >
> > What would be the best way to make the code calling cancel() (and 
> > possibly
> > join()) wait on sucessful completion?  In note that their is an 
> > asyncronous
> > cancel mode, so one can not assume that cancel() has successfully 
> > completed
> > before it returns.
> 
> In general, there's no good way to do this...since cancel() should be 
> used as a request, or hint, not as an absolute.  In general, code 
> executing Thread::Cancel needs to guard against the fact that this is 
> only a request...one can try something like:
> 
> pseudo code:
> 
> MyDerivedThread myThread = new MyDerivedThread()
> 
> // Initialize and run...
> 
> myThread->cancel();
> 
> while(myThread->isRunning()) {
> 	OpenThreads::Thread::YieldCurrentThread();
> 	usleep(1);
> }
> 
> // can now be sure the thread is not running.
> 
> Join could work the same way, but should block until the threads 
> actually join, so the while loop would be unecessary.
> 
> NOTE: I make no bones about the fact that I have no idea how this is 
> implemented with Win32Threads, but the pthreads version should work 
> fine...
> 
> sean
> 

I'm confused... what does Robert mean by "wait for successful completion"?
Something other than what join() does?
(I assume so, otherwise he wouldn't be asking... but what?)

Don


-- 
Don Hatch
ha...@pl...
http://www.plunk.org/~hatch/