Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at