Re: New win32 signals patch (3)

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Magnus Hagander ' <mha(at)sollentuna(dot)net>, 'pgsql-hackers-win32 ' <pgsql-hackers-win32(at)postgresql(dot)org>
Cc: "'pgsql-patches(at)postgresql(dot)org '" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: New win32 signals patch (3)
Date: 2004-02-04 03:32:50
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F2CA@harris.memetrics.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32 pgsql-patches

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

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Magnus Hagander 2004-02-04 09:03:12 Re: New win32 signals patch (3)
Previous Message Magnus Hagander 2004-02-03 23:46:02 New win32 signals patch (3)

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2004-02-04 05:57:21 Re: pg_generate_sequence and info_schema patch (Was: SELECT
Previous Message Neil Conway 2004-02-04 01:04:22 Re: fix memcpy() overlap