[c++-pthreads] Restating the Jason model
Alexander Terekhov
boo at terekhov.de
Tue Jan 13 13:28:45 UTC 2004
Dave Butenhof wrote:
[...]
> >Anything else?
> >
> >
> Yes; but I don't yet know what it is. ;-)
2-phase EH (with fixed throw spec semantics) and "intelligent" cancel
request delivery. I thought you were in favor of it...
http://groups.google.com/groups?selm=3ec0f83b%40usenet01.boi.hp.com
<quote>
OK, fine. Let's standardize on a low-level exception support environment
with DETACHED 2-phase PC-mapped exceptions. On the first "search" phase,
the handler (if any) associated with each PC region that's active on the
call stack is presented (in order from most recent frame) with the cause of
the exception; say, a status code and arbitrary counted argument list. At
any point, a handler may determine that an UNWIND is necessary, targeting a
particular active stack frame. All handlers from the "inmost" out to that
frame's will be activated a second time with a status that indicates an
UNWIND is in progress. If the search phase reaches the base frame with no
unwind, then a core dump is taken. Only on the UNWIND phase should any
handler make actual changes in any program state, consistent with the
unwinding of that frame. Thus, cleanup occurs only when an UNWIND has been
ordered -- and of course it may also be conditionalized on the identity of
the exception that's unwinding.
This provides everything you need for your conditional "cleanup only if
unwind will occur" syntax, in C++ and/or C. It still provides sufficient
support for existing exception models like Ada and Modula-2+ that already
have 'finally' and depend on a traditional interpretation. (Having any of
these frames active will cause your conditional cleanup for any "inner
frame" to fire because there WILL be an unwind, but that's life.)
(What I've described, by the way, is essentially how the OpenVMS condition
handling facility has worked since 1977, though many users have always
ignored the unenforced recommendation that cleanup be done only on unwind.)
</quote>
regards,
alexander.
More information about the c++-pthreads
mailing list