Re: [c++-pthreads] Re: thread-safety definition

[Ted Baker <baker@xxxxxxxxxx>]

> I suspect that destructors should be implicitly "no cancel zones".  
> (Someone expressed a concern about runtime overhead; but the cost of 
> enabling and disabling cancel CAN be made extremely low by collusion 
> between C++ and the thread library. That's an implementation detail the 

Good point.  If the overhead of maintaining a per-thread
cancellability bit is too high for you, you can use what I called
"static mapping" in my 1986 paper on how to implement Ada
exceptions (sorry I don't know the C++ term for it), e.g., the
linker and compiler provide a table of address ranges over which
cancellation is permitted.  This has no runtime overhead until you
reach a cancellation point, at which point you need to check the
stack of return addresses to decide whether it is safe to cancel.
This increases the cost of polling for cancellation, but only
that.

--Ted

> standard doesn't necessarily need to explicitly address.) There might be 
> cases where someone really wants an indefinite blocking operation in a 
> destructor (perhaps to disconnect from a remote server), and might want 
> that to be cancellable. I think that's a rare special case, and could 
> probably be handled by manually enabling cancel over that range of code, 
> catching/finalizing the cancel if it occurs, cleaning up, restoring the 
> original "cancel disabled" state, and then calling 
> pthread_cancel(pthread_self()) to re-pend the cancel. Perhaps (though it 
> seems doubtful) this might be common enough to justify some special 
> syntax to encapsulate the mechanism and avoid errors.
> 
> -- 
> /--------------------[ David.Butenhof@xxxxxx ]--------------------\
> | Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
> |     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
> \----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/