[boost] Re: Basic guarantee and synchronized multiple updates.

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-09-28 11:59:50

David Abrahams wrote:
> 
> From: "Alexander Terekhov" <terekhov_at_[hidden]>
> 
> > David Abrahams also wrote: <another article>
> > [...]
> > > > especially if you are trying to
> > > > write safe portable code (besides, they could be implemented as
> > > "really-C++"
> > > > exceptions on a given platform too).
> > >
> > > In that case, try/catch would be fine.
> >
> > Nope. You wouldn't really want to ALWAYS have {partial} unwinding on
> > std::logic_error
> 
> I don't really have a choice.
> 
> > (unless you *really really* want it for some reason
> > that is beyond my understanding and/or imagination), would you? ;-)
> 
> I really wouldn't want std::logic_error in the first place, but if someone
> is so foolish as to throw one, there *will* be stack unwinding. That's how
> exceptions work (yeah, I know there are conditions under which you can
> terminate without unwinding, but that's what assert/abort() is for).

But there are really quite a few "corner cases" when the caller/user 
should have a right to decide whether this or that exception is meant 
for local recovery (will be caught) or should rather result in a nice 
core dump (at throw point) with recovery actions being done on some 
higher level. I'll try to give an example: on mainframes programmers 
are supposed to document address space size requirements (depending on 
the config/input/workload) for their programs. System programmers and 
operators use this information for capacity planning, etc. in order to 
achieve "reasonable" performance/throughput on their systems (or just 
buy "more hardware" ;-) ). They really don't want to see those dumb 
"out-of-memory" errors. Quite often, running out of memory just means 
that something was leaking/looping and/or the calculations were just 
wrong. In any event, our service folks really want to see a full dump, 
instead of kinda silly: "catch(const std::exception& e) { cerr << 
e->what(); exit( EXIT_FAILURE ); }"-like stuff.

> > Frankly, do YOU *also* kinda "doesn't seem to care"(*) with respect
> > to thread cancel/exit safety of your code (given that sort of "brain-
> > dead" *forced unwinding* IS adopted by many many C++ vendors/platforms
> > presently)? What am I missing, Mr. Abrahams?
> 
> I don't seem to care so much because most of my code isn't written with
> thread safety in mind and doesn't have to run in multithreaded contexts.
> I'll worry about that when I have users who need it, knowledge of the
> platforms I'm targeting, and an environment in which to test what I've
> done.

Fair enough. If/when you'll see PJP, please drop these links "on him":

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/EDCLB130/FRONT_1.1
("Standard C++ Library Reference,...The documentation, which is available at")

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CBCPG130/1.2.3
("1.2.3 Class libraries")

"....
 z/OS V1R2 C/C++ provides the following class libraries, 
 which are all thread-safe: 

 Standard C++ Library, including the Standard Template Library (STL), 
 and other library features of ISO C++ 1998
 ...."

<pretty much the same goes for AIX/IBM Visual Age C++ as well>

regards,
alexander.