Re: psiginfo

[Bruno Haible]

Eric Blake wrote:
> Meanwhile, I'm looking at the POSIX definition of psiginfo, and wondering how 
> on earth it is intended to be used!  psiginfo is intentionally omitted from 
> the 
> list of async-signal-safe functions, but you only ever get a populated 
> siginfo_t* in the context of a signal handler ...
> so I don't see how ANY portable application could expect to 
> call psiginfo and get well-defined results (you can't safely call it in a 
> signal handler

You can't call it safely in signal handlers that have been called
asynchronously. But in SIGFPE, SIGSEGV, SIGILL handlers, in practice, you
are pretty sure that no libc lock is currently taken and the libc
datastructures are ok, and then you can use psiginfo.

> and you can't safely preserve the siginfo_t from a handler to 
> later safely call it after returning from the handler).

Why not? siginfo_t is a struct, you can copy it out into preallocated memory.

> and siginfo_t is not compatible with sig_atomic_t

The relation between siginfo_t and sig_atomic_t is irrelevant. Just
precallocate a buffer of siginfo_t structs:

  #define PREALLOCATED 100
  static volatile siginfo_t array[PREALLOCATED];
  static volatile int counter;

and in the signal handler you do

  if (counter < PREALLOCATED)
    {
      array[counter] = *siginfo_argument_from_signal_handler;
      counter++;
    }

The main program can then inspect the 'array' and 'counter' variables and
call  psiginfo (&array [counter - 1], NULL). Details regarding the lock-free
communication get tricky, of course. But there is no hurdle prohibiting
you from copying a siginfo_t from one piece of memory to another.

Bruno