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

[Alexander Terekhov <boo@xxxxxxxxxxx>]

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? 

If a function that I wrap with a try-block has an exception 
specification then I know that catch(...) can only catch exceptions 
specified in that throw spec (silly implicit catch(...) aside for a 
moment).

#include <cthread>

void f() throw() {
  try {
    std::pthread_testcancel(); // or think of fclose() like stuff
  }
  catch(...) { // only thread cancel request can be caught here
    /* nothrow */
  }
}

shall be equivalent to

#include <cthread>

void f() throw() {
  try {
    std::pthread_testcancel(); // or think of fclose() like stuff
  }
  catch(std::thread_cancel_request const &) {
    /* nothrow */
  }
}

in my view. Note that C++ library implementations are not allowed to 
lessen exception-specifications defined in the C++ standard 
(incidentally, this is the source of conflict with respect to POSIX 
cancellation points), they can only strengthen them, if they want.

> And why are you afraid? ;-)

To me, there's nothing wrong with catch(...) as long as it's used 
"properly" (see "is catch(...) safe" thread at c.l.c++.mod). I don't
want any special cases or treatment for thread_cancel_request and/or 
thread_exit_request/value. People should simply fix the code because 
it's just impossible to define a model that would add thread cancel 
and a) not break this or that existing cancel unaware code, plus b) 
not make writing new cancel aware code sort of "painful" or 
"inconvenient".

regards,
alexander.

P.S. http://google.com/groups?selm=400BBC6A.4078B8C3%40web.de