boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: jbandela_at_[hidden]
Date: 2001-08-03 18:27:12

In GOTW 61 Herb Sutter writes the following

The Importance of "Big-A" Atomicity
As pointed out by Abrahams and Colvin and others, to guarantee any 
kind of exception safety it is essential that certain operations -- 
notable destructors and deallocation functions -- be required not to 
throw. That is, they must be at least A-safe. We rely on this in all 
sorts of situations, notably:

- The "do all the work off to the side, and commit using only 
nonthrowing operations" method is not possible if there are no 
suitable nonthrowing (A-safe) operations.

- The related "create a temporary and Swap()" method, which is the 
standard form of exception-safe copy assignment, is not possible 
without a nonthrowing (A-safe) Swap().

An interesting point raised by Greg Colvin is that for this reason it 
does not appear to be possible to write exception-safe code in Java. 
The Java specification currently allows the JVM to throw an exception 
at any time at arbitrary points in the program, for example 
asynchronously when stop is called on a Thread object. In practice it 
isn't that bad, but it is worrisome that the Java specification can 
apparently be shown to preclude writing exception-safe code because 
there is no way to absolutely guarantee A-safe operations in Java.

-----

Are the statements about arbitrary exceptions precluding the writing 
of exception safe code still valid? It seems to me that using 
exceptions to interrupt threads would, according to the above 
passage, preclude writing guaranteed exception-safe code. 

Regards,

John R. Bandela

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> I have not looked at the threading case in particular, but I do 
want to
> weigh in on the side of "exceptions don't have to be errors". 
Exceptions are
> appropriate where the execution model and (lack of) efficiency 
matches the
> needs of the programmer. I've used exceptions successfully to allow 
users to
> cancel long operations in a GUI app: I scattered occasional calls 
to the
> function which polled for the cancel keystroke through my 
operations, and
> threw an exception when it was found that the user had cancelled.
> 
> -Dave
> 
> ----- Original Message -----
> From: "Alexander Terekhov" <terekhov_at_d...>
> To: <boost_at_y...>
> Sent: Friday, August 03, 2001 2:07 PM
> Subject: Re: boost.threads [was RE: [boost] Re: sockets /network 
programming
> Requirements]
> 
> 
> >
> > > A good attempt at bypassing the problem, but it doesn't cover 
all the
> > > basis.  This *ISN'T* really an exception but instead is an 
attempt at
> > > program flow control.
> >
> > sorry, it is the same (ISO/IEC 14882:1998(E) pg 291):
> >
> > "Exception handling provides a way of transferring control
> >  and information from a point in the execution of a program to
> >  an exception handler associated with a point previously passed
> >  by the execution."
> >
> > > The problem is that code can still catch these
> > > exceptions, even if you insure they are rethrown.  Imagine, for
> > > example, a catch block coded as:
> > >
> > > try
> > > {
> > > }
> > > catch(...)
> > > {
> > >    LogError();
> > >    exit();
> > > }
> > >
> > > The programmer probably doesn't want LogError() called for this 
non-
> > > error, and he definately doesn't want the program to exit.
> >
> > but then his code would never call thread::exit so there
> > will be no problems. also, IMHO catch(...) without "throw;"
> > or program termination is inherently flawed (e.g. who is
> > supposed to delete the object thrown by not so smart pointer,
> > etc) so i do not see any good reasons not to provide
> > exception based thread::exit even w/o catch(...)
> > workarounds.
> >
> > regards,
> > alexander.
> >
> >
> >
> > Info: http://www.boost.org  Unsubscribe:
> <mailto:boost-unsubscribe_at_y...>
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
> >
> >
> >