Обсуждение: Re: socket calls in signal handler (WAS: APC + socket restrictions un der Win32?)

>> Hi all,
>>
>> Was just discussing the issues related to the above off list
>with Magnus:
>>
>http://archives.postgresql.org/pgsql-hackers->win32/2004-03/msg00041.ph
p
>>
>> Whilst we can think of a number of work-arounds (the simplest being a
>> suggestion by Magnus: set a flag, like APCcalled, to false before the
>> select() call, and repeat the select() if APCcalled == true
>on return from
>> select), we were wondering if having socket calls inside
>signal handlers was
>> a good idea in any case?
>
>Is this a win32 only thing, or is it more general?
>
>OpenBSD for instance has some documentation on which functions
>are safe to be called from a signal handler, and socket
>operations aren't part of it.  See for isntance their manpages
>about signal and sigaction.

This is very interesting - it points towards this being a general
problem and not just Win32. I was expecting something along this line,
since you should generally be very restrictive with what is done in a
signal handler, and socket I/O can be a lot (say it blocks, etc).

To me this sounds like we have to make a general solution, and not win32
specific, to get the socket calls out of the signal handler. This seems
to be the only one that uses it, so it should be a fairly small change.

Since in this case, it's a simple pid being sent up, it could probably
be done as simple as: (ok, not patch, just text, but..)

1) Change CleanupProc() in postmaster.c to put the pid in a list or an
array instead of calling pgstat_beterm().
2) At the select() call in ServerLoop(), poll this queue and post out
anything that has happened since last loop using pgstat_beterm().


Does this sound reasonable?

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> To me this sounds like we have to make a general solution, and not win32
> specific, to get the socket calls out of the signal handler.

Hold on one second here.  I thought this thread was discussing some
local problem in the Win32 workaround for lack of signals?

The postmaster's use of nominally unsafe stuff in signal handlers is not
and never has been a problem, because there is only one place in the
main loop where signals are unblocked, thus no possibility for something
to interrupt something else.  I don't like the idea of redesigning that
code just because someone misunderstands it.
        regards, tom lane