Re: Digest Number 754

From: Smokey the Phat Basset (hys420_at_[hidden])
Date: 2001-08-05 13:57:13

--- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> 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.
> 

sounds like that policy swung a bit much in the opposite direction 
(vs pthreads which has more flexibility to deliver preemptive 
cancellation signals)..

> 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.
>  

Aside from the thread-cancellation issue, I think to some extent this 
holds true just as much for C++, in that you can never really 
guarantee that even the strictest of no-throw code won't bust an 
accvio or stack overflow or encounter some other asynchronous OS 
exception which is really outside the control of the program itself 
(vs thread-cancellation, which is an unstoppable event but should 
fall somewhat under the program's control). Take std::swap() for 
example, even the act of allocating the stack space for the temporary 
could potentially overflow the stack, and there's probably nothing 
much that can really be done about it, but it is guaranteed not to 
emit any C++-based exceptions. I don't think it's really appropriate 
for no-throw code to be attempting to allocate memory on the heap, 
which is clearly defined as a throwing operation, so I would discount 
that particular exception from this scenario. Barring internal 
failure of the program or computer (or virtual machine) itself or 
other external circumstances beyond the control of the language, it 
seems that no-throw code can be written that guarantees not to allow 
any C++-based exceptions to escape (and similarly in java, other than 
the thread-cancellation stuff).

later,
hys