>> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
