Re: [boost] Re: Digest Number 754

From: Greg Colvin (greg_at_[hidden])
Date: 2001-08-06 11:23:51

From: Smokey the Phat Basset <hys420_at_[hidden]>
> --- 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)..

Yeah, but pthreads is not available on the platforms we need
to port java too.

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

I think that throwing exceptions for stack overflow and such is
bordering on non-conformance, perhaps being allowable only through
the "undefined behavior" escape hatch.

Anyway, I wouldn't claim that C++ is hugely better than java in this
respect, but I think the Standard is fairly clear about where you do
and don't risk undefined behavior.  The proprietary java specs I have
seen are nowhere near as clear, and we are not likely to ever see a
Standard.  But java doesn't really matter much to this discussion,
except as a source of good and bad examples of how to do a portable
thread implementation.