🚀 go-pugleaf

David Brownell (brownell@ix.netcom.com) wrote:
: Tom Payne wrote:
[...]
: > 
: > The standards process is the appropriate forum for such vendor
: > agreement.  Unfortunately, the standards bodies have failed to provide
: > the necessary leadership in the areas involving concurrency and
: > asynchrony.  Perhaps, these bodies simply have other fish to fry --
: > getting the current standard completed is an monumental task.
: 
: Well, POSIX.1c happened; it's the ANSI/ISO C++ team that's said such
: issues are "out of scope" for now.  I don't think it's realistic to
: expect POSIX to produce a C++ binding at this time, given some of the
: issues raised in my writeup above.  Nor do I think vendors should be
: gratuitously diverging, even lacking a formal standards framework.

Unfortunately, competition begets for product differentiation, and
vendors must compete.  Standardization is the responsibility of
standards bodies, who, I realize, must separate and prioritize their
concerns.  Nevertheless ...
: > ... a C++ program (with defined behavior)
: > cannot deal efficiently with some of the simplest asynchrony, e.g., a
: > hardware-detected exception cannot generate a program exception,
: > unless the program explicitly polls for it, thus, requiring
: > unacceptable overhead both in running time and programming effort.
: 
: Some of us don't think that it's necessarily a good thing to complicate
: C++ exception processing further -- it's a synchronous mechanism now.
: I'd hope that the current mechanism for asynchrony (signals) would just
: be fixed to address your issues!

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.  

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.

Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]