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

[Dave Butenhof <David.Butenhof@xxxxxx>]

David Abrahams wrote:

> Dave Butenhof <David.Butenhof@xxxxxx> writes:
>  
>
> > David Abrahams wrote:
> >    
> >
> > > Mathieu Lacage <Mathieu.Lacage@xxxxxxxxxxxxxxx> writes:
> > >
> > > > It looks like what everyone is trying to achieve here is a way for C++
> > > > authors to write thread-safe libraries.    
> > > I think you missed something, or maybe the main thing.  C++ authors
> > > can already write thread-safe libraries.
> > >
> > > What I'm trying to achieve is to allow existing thread-safe library
> > > code that wasn't written with POSIX cancellations in mind to be used
> > > easily in a POSIX environment.
> > Right. And I maintain that this is trivial AS LONG AS you can
> > guarantee that threads running that unsafe code will never be
> > cancelled. (This seems reasonable, since obviously threads running
> > that code had never previously been subject to cancellation!) And it's
> > IMPOSSIBLE if you cannot guarantee that. 
> >    
> Please don't shout, especially to emphasize something I disagree with
> so fundamentally. ;-)
>  
Ah. I see the problem. I believe that you neglected to file in 
triplicate the official "List of all matters with which I disagree so 
please don't shout when discussing them" form. Didn't you? ;-)

> > The code must be analyzed and corrected, point by point; and the
> > analysis (and possibly the correction as well) is easier if
> > cancellation is a structured exception than if it's a return status
> > handled in various "unique" ways by each routine.
> >    
> If you make cancellations behave sufficiently like an ordinary C++
> exception (either of Nathan's or Jason's models would do that I think)
> then it's neither "IMPOSSIBLE" nor even difficult.  A great deal of
> thread-safe exception-safe C++ library code would behave perfectly
> well under those conditions.
>  
Well, it should be no surprise that this discussion has fragmented into 
too many different little pathways for anyone to keep track of them.

If cancel is implemented completely as a "full stature" C++ exception, 
and none of the "exception safe" code does anything silly like 
"catch(...)" without a re-throw, then, yes, it's likely to be reasonably 
cancel-safe. (Though some code might need to be aware that an uncaught 
cancel will terminate the thread rather than the process!)

But I was really responding to the ideas about turning cancel into a 
return status, which seemed to be associated with the notion that this 
would somehow make it more transparent to the ported code. (I happen to 
think the OPPOSITE is true. Am I allowed to shout there? ;-) ) This may 
also be associated with some implications of a statement about porting 
"pthread code" into the new C++ environment; and since "pthread" code is 
by definition C rather than C++ (no C++ in POSIX!), it cannot be made 
portably exception safe. (Of course the same C extensions on Tru64 and 
OpenVMS that allow handling of cancel allow cleanup on propagation of 
any other exception; but that's an extension.)

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