Re: [boost] Digest Number 754

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-05 13:18:44

From: Hillel Y. Sims <hys420_at_[hidden]>
> Pthreads has a limited, well-defined set of cancellation points (under
> ordinary conditions), thus is it 100% possible and not that difficult to
> write completely non-throwing code even with thread-cancellation
> implemented in terms of exceptions in a pthreads-based environment, by
> simply avoiding any functions that could potentially evoke a
> thread-cancellation exception (since it's not valid to use catch (...) {}
> to swallow these exceptions, we would have to completely avoid invoking
> any of these calls inside true non-throwing code, but that doesn't really
> seem like a horrible restriction).
> 
> (I don't really do Windows, so I don't know if it has similar thread
> cancellation semantics..)

I should know, but I don't.  I do know that thread cancellation has
proved troublesome enough in java that Thread.stop(), which forces
a ThreadDeath exception to be thrown, has been deprecated in favor
of Thread.interrupt(), which will wake up a sleeping thread but
which counts on the thread to check Thread.isInterrupted().  The
problem isn't so much asynchronous cancellation as the difficulty
of ensuring the consistency of shared objects.

> That's pretty funny about Java only having asynchronous cancellation, I
> didn't know that. I would blow a gasket if I had to deal with asynchronous
> cancellation throughout my entire application.

The point I was making about exception safety in java is that, as
Dave Abrahams has shown, writing exception recovery code usually
requires that certain functions can be guaranteed not to throw
exceptions.  It appears that no such guarantee can be made for java
code.  Even if you avoid Thread.stop() you cannot avoid the
VirtualMachineError classes like InternalError, StackOverFlowError,
OutOfMemoryError, and the dreaded UnknownError.  In practice it isn't
so bad, as it is clear enough on most implementations how to avoid
running out of stack or memory, but as far as I know Sun's
specifications allow for VirtualMachineError exceptions to be thrown
anywhere, anytime.  But I have not been following Sun's pseudo-
standardization "community" process, so I could well be wrong about
that.
 
> hys
> 
> -----------
> 
> Message: 17
>    Date: Fri, 03 Aug 2001 23:27:12 -0000
>    From: jbandela_at_[hidden]
> Subject: boost.threads [was RE: Re: sockets /network programming
> Requirements]
> 
> 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
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> 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/ 
> 
>