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

[Alexander Terekhov]

Ted Baker wrote:
[...]
> There is no need for a destructor to be aware of cancellation.

my_file::~my_file() throw() {
  fclose(/*...*/); // doesn't throw; cancel is unexpected (even if thread
                   // cancel state is equal here to PTHREAD_CANCEL_ENABLE)
}

void jason() throw() {
  std::enable_thread_cancel(); // re-enable cancel state
  std::thread_self().cancel(); // re-inject cancel request
}

my_other_file::~my_other_file() throw() {
  bool canceled_before = std::unwinding<std::thread_cancel_request>(this);
  try {
    if (canceled_before) jason();
    fclose(/*...*/); // can (should "if (canceled before)") throw
    /*std::*/pthread_testcancel(); // fix "may occur" mess
  }
  catch (std::thread_cancel_request const &) {
    if (!canceled_before) jason();
  }
}

Now, in your model with cancellation ALWAYS disabled while running 
destructors (not only when acting upon a cancel request delivery... 
thread_exit aside for a moment), I'd have to add enable/disable RAII
guard object (and that's in addition to save-disable/restore internal
"C++ runtime" managment cost)... and I'd probably have to get rid of 
ability to control cancelability of ~my_other_file() internal stuff 
via thread cancel state set outside. Oder? I really don't like that.

[...]
> > Burning processing cycles on cancel enable/disable is another issue
> > here, BTW.
> 
> Yes, but it need not be a *huge* amount of cycles.  ...

ES (throw specs) should have no runtime cost other than some extra 
info for the search phase. OTOH, save-disable/restore burns cycles 
(keystrokes aside for a moment) no matter whether you hit some 
cancellation point [or async-cancel region] *with cancel request 
pending* or not. 

regards,
alexander.