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

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-03 19:51:43

From: <jbandela_at_[hidden]>
> 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.

I only vaguely recall having this discussion with Herb, but perhaps
he can refresh my memory.

My intuition remains that the java specification is deficient in
this way.  But I wouldn't claim to have "shown" any such thing.

> 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/
> > >
> > >
> > >
> 
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>