🚀 go-pugleaf

In article <4l8pud$3t8@galaxy.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote:
>Fixing the stantard so that signal handlers can read global data (with
>appropriate qualifications on the significance of the result) would be
>a significant help.  The complexity here is only in the wording of the
>standard.  

Nope, there's appalling interactions with constructors and destructors.

>The second major need is to allow a signal to force an exception in
>without the program polling for it.  Complexity is never "necessarily
>a good thing," unless the benefits outweigh the costs.  The benefits
>would be
>
>  *  lower latency exception responses to signals
>
>  *  elimination of the CPU overhead of polling
>
>  *  much simpler programming for such situation.
>
>The cost would be in the increased complexity of the implementation
>and CPU overhead caused by the implementation.  In a thread on this
>topic a couple months ago, David Chase gave an implementation strategy
>based on range tables that seemed to involve no CPU overhead and whose
>complexity seemed reasonable.

The DISPATCH has reasonable complexity.  Unfortunately, unless both
the compiler and the language are engineered to provide abort/commit
semantics for every single operation, you end up with unsafe portions
of code -- if an exception is thrown in one of those portions of code,
you're potentially hosed (as in, how inconsistent would you like your
data structures to get?)  The destructor/constructor/automatic-object
semantics already in place make this non-trivial.

Personally, I think this might be a cool thing, but it's a little late
for that now (when I write code that I want to work, which is most of
the time, I work in the abort-commit style -- either the operation
succeeds, or it virtually/semantically does "nothing", leaving the
data structures in a valid state.  Carried down to the load/store
level, this can be a little much).  It would almost certainly require
the addition of garbage collection to the language, else people would
certainly lose their minds (and you could *never* be sure that your
code was really leak-tight -- run-time leak detectors will merely tell
you about a single run of a program, and these leaks will be
timing-dependent).

And no, I'm not sure that any even slightly popular language does this
right.  I haven't studied Ada's approach to this problem in detail, so
they might have gotten it right.  I think their approach is to allow
programmers to delimit critical sections during which interrupts are
suspended (think about implementing that efficiently on your favorite
machine for a minute).  Another approach is to allow the execution of
roll-back code if an operation is interrupted, but then you've got to
write the roll-back code.  I suspect that this is the most efficient
route to take, but it is really non-trivial at the programmer level
(compilers can do this with stack frames, but compilers are very
patient animals).

speaking for myself,

David Chase





[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]