[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Exception handling
With respect to 754R non-resumable "ThrowException", David Hough wrote:
As the text emphasizes, results in interrupted
calculations need not be determinate or reproducible.
That's not the problem Nick and I were addressing. The problem lies
below the abstractions (such as variables) exposed by the language.
For example, at the physical point of interruption, typically several
instructions beyond the logical point (in systems without a precise
interrupt mode or capability), a stack frame may have been partially
unwound. It is even possible that two frames were unwound, or that
a new frame was already (perhaps partially) activated.
Preventing this type of uncertainty requires inserting synchronising
instructions (interrupt reflection barriers) at block-entry-and-exit
points, which costs plenty even when no interruptions occur, or by
leaving breadcrumbs as I suggested earlier, which at least defers most
of the cost to internal exception handling, but limits to some extent
what the thrower can do -- though termination of an outer context is
something that can almost always be done in this case. (Where it may
not be possible is if the breadcrumbs indicate that the outer context
should have been reached already, so that its state may be in doubt.
But that can be dealt with by placing a serious barrier instruction at
that boundary, so it cannot be partially crossed, and the cost of that
may not matter, as it is not in a loop.)
Michel.
Sent: 2007-06-07 14:48:40 UTC