Hi,
On 2015-08-30 14:59:41 -0400, Tom Lane wrote:
> 1. No buildfarm member in the available history (going back to 2012-01-01)
> has ever reported not having the POSIX signal interface, nor sig_atomic_t.
> (We don't run the POSIX-signals check on Windows systems, though.)
We, afaik, don't use any signals on windows anyway...
> I think we should rip out the configure checks for HAVE_POSIX_SIGNALS,
> HAVE_SIGPROCMASK, HAVE_SIGSETJMP, and probably HAVE_SIG_ATOMIC_T, as well
> as the C code that tries to make up for not having these things (on
> non-Windows systems that is). It's not being exercised and it's fair to
> doubt that those code paths would even work reliably anymore. For
> instance, it seems likely that our current latch code has never been run
> on a system without these APIs, and even more likely that Andres' recent
> fooling around with signal handling (eg commit 6753333f5) has never been
> checked on such a system.
Sounds good to me.
> HAVE_SIG_ATOMIC_T is a debatable case, in that the only thing we're
> doing with it is c.h's
>
> /* sig_atomic_t is required by ANSI C, but may be missing on old platforms */
> #ifndef HAVE_SIG_ATOMIC_T
> typedef int sig_atomic_t;
> #endif
>
> which should be safe enough (if int isn't atomically stored/fetched we
> already have big problems elsewhere). Still, the configure test for it
> appears to be a complete waste of cycles.
What are you proposing to do instead? Replace sig_atomic_t by int
everywhere? Or unconditionally do the typedef? Because the latter won't
work well if it's already typedef'ed...
Andres
