>> 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?

It was from the beginning (not directly the lack of signals, but
misbehaviour of select() with respect to socket functions called on APCs
which are used for signals). But then Kurt pointed out that what we are
doing now may be wrong from other aspects.

What we do now is supposedly unsafe at least on OpenBSD, according to
their manpages:
http://www.openbsd.org/cgi-bin/man.cgi?query=signal&apropos=0&sektion=0&
manpath=OpenBSD+Current&arch=i386&format=html

It says:
"Most functions not in the above lists are considered to be unsafe with
     respect to signals.  That is to say, the behaviour of such
functions when
     called from a signal handler is undefined."

This sounds a bit scary to me. (There are no socket functions on the
list, so the pgstat_beterm behaviour is undefined at least on OpenBSD
from what I can tell)


>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.


You're saying the above is not valid because we block signals?

The issue specific to win32 is connected to the select() call, which is
indeed in such an area of the code. But the reference above to OpenBSD
appears to be for signal handlers in general. And that should not be
affected by signal blocking, no?

It clearly works now, but it sounds like a dangerous path to me. But it
can certainly be me misunderstanding the whole thing :-)

A localized win32 fix is probably a bit easier to do (just a wrapper
around select), but I figured you'd want the generic case taken care of.
Just let me/us know which is preferred.


//Magnus

Mon, 8 Mar 2004 23:33:17 +0100
"Magnus Hagander" <mha@sollentuna.net>
Re: socket calls in signal handler (WAS: APC + socket restrictions un
	der Win32?)
On Mon, Mar 08, 2004 at 11:33:17PM +0100, Magnus Hagander wrote:
> 
> >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.
> 
> 
> You're saying the above is not valid because we block signals?

It's all about reentrance of functions where it's not safe to do
so.

Either you avoid it in the signal handler or you avoid it by only
allowing it during a "safe" period.


Kurt


Mon, 8 Mar 2004 23:55:20 +0100
Kurt Roeckx <Q@ping.be>
Re: socket calls in signal handler (WAS: APC + socket restrictions un
	der Win32?)