setjmp/longjmp vs 754R throw exception

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

David Hough wrote:
> But I don't see how a programming environment that handles programs with
> setjmp/longjmp is going to have much more trouble handling 754R throw.
> Even "terminate with message" is just an implicit longjmp far enough back

The issue is the nesting distance between the catch and the throw, or the
(implied) setjmp and the (implied) longjmp.  Without barriers, and with
insufficient separation, an asynchronous longjmp could be triggered below
the setjmp.  With "terminate" sufficient separation can be guaranteed by
the "system".

To the extent that an implementation of IEEE Throw need not know the
actual source, it may be sufficient to install few enough trap barriers
that it ends up working just fine.  (If nested catch declarations are
supported, there must be a trap barrier to prevent an exception reflection
to cross the nested declaration, but that should be acceptable too.)

All this predicated however on the availability of trap barriers (in the
absence of synchronous exceptions), and Nick seems to know platforms where
such instructions are privileged.  On PowerPC user-level instructions that
access the floating-point control register can be used (when in non-precise
mode; PPC has several levels of control, but that choice is privileged),
and IBM System z has precise IEEE traps -- that's as much as I know.

SO this is the sense in which "terminate" is more general -- it accomodates
platforms with imprecise exceptions and no user-level trap barriers.

Michel.
Sent: 2007-06-08 00:09:28 UTC