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

[Alexander Terekhov <boo@xxxxxxxxxxx>]

Fergus Henderson wrote:
[...]
> > In the current POSIX/C++ environment one must disable/restore-old
> > cancellation state in the destructors that call POSIX cancellation
> > points anyway (I mean "general cancel-safe library" stuff). That
> > does ensure proper cleanup.
> 
> Yes, to the extent that there _is_ a de facto standard current POSIX/C++
> environment, it does not use sticky cancels, and so it is possible to
> do proper cleanup.

I suppose that even under the Nathan's "sticky cancels model", 
cancellation points are meant to be idle (with respect to 
cancellation) when cancellation state is set to 
PTHREAD_CANCEL_DISABLE. 

> 
> > David Abrahams wrote:
> > > OK, thanks for the explanation.  Sounds like an argument for Jason's
> > > exceptions that re-assert cancel when they're destroyed.
> >
> > Making broken code a bit less broken is hardly the right design
> > rationale. Presuming that we'll get a standard named thread cancel
> > request exception,
> 
> I hope that we get a standard base class for thread cancel request
> exceptions, and that we provide a way for code which requests a thread
> cancellation to specify an object of any class derived from this standard
> base class, and have that object (or a copy of it) be the object thrown
> in the cancelled thread.

This would extend the current POSIX model and would also mean that "C++ 
version" of pthread_cancel() and cancel request delivery "in C++" would 
need to have "release" and "acquire" memory synchronization semantics 
respectively. 

Well, I guess that I should now better send my forthcoming reply to 
your recent private message to the list. Oder? ;-)

> 
> > his "fix" (with respect to broken C++ libraries)
> > is nothing but
> >
> > catch(...) {
> >
> >   /* ... no re-throw here ... */
> >
> >   try {
> >     throw;
> >   }
> >   catch(std::thread_cancel_request const &) {
> >     std::thread_enable_cancel(); // re-enable cancel
> >     std::thread_self().cancel(); // re-inject cancel request
> >   }
> >   catch(...) { }
> >
> > }
> 
> There's a big difference between doing that automatically
> and doing it manually.  If it is done automatically, you
> can be sure that the programmer won't accidentally forget
> to do it.

I don't wont it to be done automatically because there is "just a 
few" valid scenarios where it would make sense to do it... and
broken C++ libraries ala iostream-stuff is not one of them, IMO.

regards,
alexander.