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

[Dave Butenhof <David.Butenhof@xxxxxx>]

Alexander Terekhov wrote:

> Dave Butenhof wrote:
> [...]
>  
>
> > than explicit API. I was thinking in terms of disabling cancel within a
> > 'throw()' scope... but there might be other conditions. For example, we
> > could disable inside either 'throw()' or any try with a catch(...) that
> > doesn't rethrow... unless there's an INNER scope that allows throwing
> > cancel AND with an explicit catch(cancel). So a nothrow destructor
> > (regardless of whether all destructors were implicitly nothrow or not)
> > could allow "local" cancellation by nesting a try{} catch(cancel) {}.
> >    
> This will sort of "break" catch(...), I'm afraid.
>  
How's that? And why are you afraid? ;-)

> > (Sounds too complicated; but it's something to think about. ;-) )
> >    
> The C++ incarnation of pthread_testcancel() will surely have a throw
> spec "throw(std::thread_cancel_request)" or something like that. Now
> imagine something along the lines of
>  
I take it you're arguing in favor of my parenthetical comment that such 
an analysis scheme was "too complicated"? Yes, it'd be easy to leave 
holes, which is indeed why it's complciated. If that's not what you 
meant, please explain. You love to dump "data balls" on everyone, 
Alexander, but there's always a lot of room for alternate 
interpretations of your point when you refuse to actually make it. (And 
in fact many opinions regarding whether there is in fact any point, not 
to mention whether it's worth the effort to try to guess at one.)

--
/--------------------[ 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 ]---/