1. 16
  1.  

  2. 1

    One thing that bends my mind is signal safety.

    There is very very little written about is the signal safety.

    Why? Because it’s like the multi-threaded / multi-core memory access problem… but worse.

    Partly very little is written about it because very little is guaranteed. The only thing guaranteed about it is this one small paragraph and strictly,as far as I can see only applies to C++….

    When the processing of the abstract machine is interrupted by receipt of a signal, the value of any objects with type other than volatile sig_atomic_t are unspecified, and the value of any object not of volatile sig_atomic_t that is modified by the handler becomes undefined.

    The other thing that always bugs me…. is the fine fine print on what actually happens is CPU implementation dependent.

    ie. Ultimately it doesn’t matter what the compiler and library gives you…. it’s down to the very fine fine print of the particular (version) of CPU implementation… and often the exact behaviour, even at the assembler level, is very fuzzily specified in the CPU instruction reference manuals.

    ie. Your libC may give you a sig_atomic_t….. but just try read your CPU instruction reference manual to find a guarantee that your libC’s choice of sig_atomic_t is valid…. and usually you will come away deeply troubled.