>> Tracing the bgwriter process on my machine makes it real
>obvious that in
>> fact the select delay is allowed to finish out when SIGTERM
>is received.
>> In fact worse than that: it's restarted from the beginning. If 5
>> seconds have already elapsed, another 10 still elapse before
>the select
>> exits.
>>
>> This won't do :-(. We cannot afford to fritter away 10
>seconds in the
>> SIGTERM shutdown cycle --- on typical systems init isn't
>going to give
>> us more than 20 seconds before a hard kill.
>>
>> I'd suggest reducing the delay to a second or two, or
>perhaps breaking
>> it into several 1-second waits with interrupt flag checks between.
>>
>> In the longer run we might want to rethink what we are doing with
>> SA_RESTART, but I am not sure about the implications of fooling with
>> that.
>
>I think we should at this point have some maximum value for PG_xSLEEP
>over which it falls back to a function call that does either this
>breaking up into a loop with checking InterruptPending or removes the
>SA_RESTART flag while wating for the timeout.
If you look at my win32 signals patch nr 3 (posted feb 4th), I have code
to do this for win32 in it. It breaks up select() timeouts into pieces
of 1 second and polls for win32 signals inbetween.
Turns out it wasn't necessary, since win32 *does* deliver our signals
whlie in select. So for once it's win32 that does what we want - I think
that's a first.. But it might help on another platform.
//Magnus
