Re: [pgsql-hackers-win32] New win32 signals patch (3)

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