Boost logo

Boost :

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


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