New win32 signals patch (3)
Ok, time for yet another signals patch :-)
This one replaces the one I posted yesterday - I managed to mess up my
build environment pretty bad, so while that patch worked in that one, it
would not work on a clean system. There was also a clean bug in pqselect
with regards to NULL timeouts.
As before, also adds backend/port/win32/select.c
ATM, for review, not for applying.
Anyway, step-by-step what's in the patch:
1) Per discussion with Bruce, reverts the change from kill() to pqkill()
on all platforms. Instead, #define away kill() to pqkill() in
port/win32.h, and just use kill() directly on unix platforms. Similar
changes for pqsigsetmask, except they are all local to pqsignal.h.
2) Implements pqselect() in similar ways. This function appears just as
select() to the user. Internally, it runs a loop where it polls for
signals once / second. This allows the backend to actually shut down,
since we can deliver signals to both postmaster and statistics
processes. Ordinary backends cannot yet be shut down, since they don't
use select, but a blocking recv() instead. I'll get to those soon...
3) Remove duplicate signal definitions. Signal numbers were defined in
both win32.h and pqsignal.h.
4) Adds a Console Control Handler to signals handling. This one will
pick up Ctrl-C, Ctrl-Break, Window close and System shutdown, and
translate them into a SIGINT signal. NOTE! This handler does not work if
the postmaster is started from a msys console, just if it's run from the
windows command prompt.
5) Adds a thread to the postmaster only that looks for child processes
that exit, and sends SIGCHLD to the postmaster. This is the only part of
the server that actually uses it, so no need to put it in the other
processes.
6) Fixes a typo in one of Claudios patches on a cast. Has no effect on
functionality, but causes an unnecessary warning.
With this patch, we get the following:
a) No need for that hack around StartupPID to get it to start
b) It's possible to shut the server down, in smart, fast and immidiate
mode.
The only hack required to get a working (as in can hit simple queries
against the system tables at least) backend is the errno checks in
slru.c
//Magnus
ATM, for review, not for applying.
Comments:
* Nice to see the fix for pqselect. Still want to object to the memcpy "on
the record" :-) (though, as we've discussed, they'll work as things are now)
* memcpy of an array of HANDLES will work seems to be taking advantage of
knowledge of the implementation. Use DuplicateHandle?
* Better yet, cooperation with the other functions that use the
win32_childHND/PIDArrays, by reserving the first slot for event1, could see
us doing away with both event 2 and the need for copying.
* Alternatively, I personally think the best solution is to simply fire off
a "baby-sitting" thread, in the parent, for each process that gets created,
passing it a duplicate of the (single) child handle. Each thread would just
sit there forever, waiting for the child handle to be signalled, and then
signal (ie. kill/raise) its process and terminate. AFAICS, a 2 line addition
to win32_forkexec, and a 5 line thread function to do the
waiting/signalling, and we are done. This also has the advantage that it'll
work just fine for the pgstat buffer process, which fires off the pgstat
collector process... which won't be covered by the proposed approach (and
before anyone jumps in to say this is a penalty in creating backends,
consider that the previous call would have been to CreateProcess, so a
_beginthreadex aint gonna hurt!)
Suffice to say that I'd *really* like to see this approach explored.
* If you wish to ignore either of the above two suggestions, at least put
the SetEvent(win32_sigchld_event1) and WaitForSingleObjectEx calls in a
function of their own (win32_signalChildArrayChange). Suggest
SignalObjectAndWait here. Also, afaics, no need to use the *Ex functions in
any of these cases.
* Suggest using a switch statement in win32_sigchld_sender, instead of a
nested if.
Here's hoping you agree on the "baby-sitting" thread approach,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>Import Notes
Resolved by subject fallback