Thread: Singnals code (not just win32 specific)

Hello!

The backend signals code today uses pqsignal() instead of signal() at
all places. But it uses kill() and sigsetmask() (through the macro
PG_SETMASK) directly.

I propose to change this to pqkill() and pqsigsetmask(). In pqsignal.h,
these would be #define:d back to kill() and setsigmask() for the normal
method, but would be functions on win32.

The other option is to provide our own kill() function and not rename,
but that could cause problems if we ever link against a runtime library
that provides kill() (say, the MS libraries) - we need to have our own
version of kill called. And overriding "standard library" functions by
linking in a function with the same name seems a bit kludgy to me.

While this should have no effect on the functionality on non-win32
backends, it does affect the code in places that are not win32-local.

Would a patch to change kill() to pqkill() be accepted? If not, do you
have a preference on another way to tackle the issue?

//Magnus

Magnus Hagander wrote:
> Hello!
>
> The backend signals code today uses pqsignal() instead of signal() at
> all places. But it uses kill() and sigsetmask() (through the macro
> PG_SETMASK) directly.
>
> I propose to change this to pqkill() and pqsigsetmask(). In pqsignal.h,
> these would be #define:d back to kill() and setsigmask() for the normal
> method, but would be functions on win32.

Sounds logical and more consistent than it is now.

While talking about it, I think our usage of signals is way overloaded
anyway. Any ideas how to replace it all with just one signal and a
regular message queue?


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

Jan Wieck <JanWieck@Yahoo.com> writes:
> While talking about it, I think our usage of signals is way overloaded
> anyway. Any ideas how to replace it all with just one signal and a
> regular message queue?

Fooling with the definitions of SIGTERM, SIGINT, SIGQUIT would be a
really bad idea, since we have to behave reasonably when those signals
are sent to us by code not under our control.  Unix system shutdown
pretty much forces our SIGTERM behavior, for example.

Everything else pretty much already is funneled through SIGUSR1 and
SIGUSR2.

            regards, tom lane