🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 8k8@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
: >Steve Clamage (clamage@Eng.Sun.COM) wrote:
: >: 
: >: What we put in the language standard is binding on all implementations.
: >: We try to specify things that can be implemented efficiently on any
: >: likely system. In addition, we try to specify features so that they have
: >: no cost (or nearly no cost) if you don't use them.
: >
: >Agreed!!
: >
> >: IMHO, guarantees about what you
: >: can do in an asynchronous signal handler don't meet those criteria for
: >: inclusion in the C++ standard.
: >
: >That's a rather broad conclusion, given the discussion so far.
: 
[...]
: C++, on the other hand, is intended to be dropped into (nearly) any existing
: platform and coexist with other languages on that platform. The language
: definition attempts to stay away from areas where common platforms have
: widely differing behavior for that reason. Asynchronous signal handling
: certainly varies widely among platforms.

There are certain core semantic features common to signal hanling in
all platforms, and IMHO we are not going outside them.  If a platform
support signals, all we need is a way to block (i.e., defer) them.

If the ABI implementation of signal blocking is missing or has high
overhead, then we can use global flags inside the program to reduce
blocking to setting a bit and reduce unblocking to clearing that bit
and checking whether a deferred signal has arrived (in which case
there is additional overhead to check which signal to process it).  We
can omit the handling of the blockage bit and instead use PC-range
techniques to check, on signal arrival, whether the flag would have
been set.  (David Chase has outline a more radical approach that
avoids the need to check the deferred-signal bit.)  In any case, we
are not counting on the ABI to have an efficient implementation of
signal blocking.

: It's easy to wave your hands and say that the implementation ought to
: be relatively easy to do and not overly expensive. But what if the ABI
: on a common platform makes that infeasible? If a language feature
: limits the number of platforms which allow implementation, it should be
: important to a wide range of programmers and programs.

Agreed!!  Note however that an increasing percentage of programs have
asynchornous aspects to them, under headings such as "event-driven",
"real-time", "multi-threaded", "parallel", "concurrent", etc.  

Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]