Win32 processCancelRequest/waitpid (was fork/exec patch : pre-CreateProcess finalization)
I wrote:
But I'll happily concede the point, and prove it by knocking
up a patch for it over the weekend (unless anyone else
particularly wants to).
Occurs to me I could kill 2 birds with one stone, and also implement another
Win32 sticking point, namely the waitpid changes for the Postmaster, by
having win32_forkexec do one of the following:
a) - when a backend startup is indicated, add a pid/cancel_key struct
(Backend) to this new array in shared mem
- when any child of the postmaster is started, also add a pid/HANDLE
struct to a postmaster local array (or perhaps a dlllist)
b) - when any child of the postmaster is started, add a
pid/cancel_key/HANDLE/isBackend struct to this new array in shared mem
(HANDLE for waiting on to determine child death; isBackend to separate
BackendList backends from other children)
Choosing a over b:
PRO: as we've already been through, keeps the postmaster-only data
local to the postmaster, stopping tampering from rouge backends
CON: yet more redundancy
Given recent conversations, I'm guessing (a), but any comments before going
ahead and doing it?
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>
Claudio Natoli wrote:
I wrote:
But I'll happily concede the point, and prove it by knocking
up a patch for it over the weekend (unless anyone else
particularly wants to).Occurs to me I could kill 2 birds with one stone, and also implement another
Win32 sticking point, namely the waitpid changes for the Postmaster, by
having win32_forkexec do one of the following:a) - when a backend startup is indicated, add a pid/cancel_key struct
(Backend) to this new array in shared mem
- when any child of the postmaster is started, also add a pid/HANDLE
struct to a postmaster local array (or perhaps a dlllist)b) - when any child of the postmaster is started, add a
pid/cancel_key/HANDLE/isBackend struct to this new array in shared mem(HANDLE for waiting on to determine child death; isBackend to separate
BackendList backends from other children)Choosing a over b:
PRO: as we've already been through, keeps the postmaster-only data
local to the postmaster, stopping tampering from rouge backends
CON: yet more redundancyGiven recent conversations, I'm guessing (a), but any comments before going
ahead and doing it?
As I understand it, the postmaster shared memory idea is good because
only the postmaster writes to it, and only the backends read from it.
If the HANDLE works the same way, I think you should put it into the
shared memory too, hence (b).
[ FYI, I haven't seen you on IM lately.]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
As I understand it, the postmaster shared memory idea is good because
only the postmaster writes to it, and only the backends read from it.
If the HANDLE works the same way, I think you should put it into the
shared memory too, hence (b).
But the postmaster needs to use the HANDLE, hence not (b).
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
As I understand it, the postmaster shared memory idea is good because
only the postmaster writes to it, and only the backends read from it.
If the HANDLE works the same way, I think you should put it into the
shared memory too, hence (b).But the postmaster needs to use the HANDLE, hence not (b).
That's where I was unclear. If the postmaster has to read the HANDLE,
we are better with keeping it in local memory (a).
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073