> >> What happens if process Y goes away between the time you obtain a
> >> handle for it and the time you try to run this
> DuplicateHandle call?
>
> > I can put together some quick test-code for this if you need me to?
>
> Nah, it was just a rhetorical question meant to poke a hole
> in the claim that Windows can avoid race conditions by using HANDLEs.
That's what I thought, which is why I asked first.
> AFAICS, don't-reuse-PIDs-too-quick has exact analogs that
> Windows has to solve by ensuring it doesn't reuse HANDLEs too quick.
Windows doesn't "reuse HANDLEs" in that way. Handles are like file
descriptors.
The kernel structure represnting the process has a *process id*, not a
handle. That is what uniquely identifies the process. (In the kernel
it's often referred to as a "client id").
The process structure will be held as long as anybody has an open handle
to the process. Thus, as long as this happens, the pid *cannot* be
reused. So one way to assure the pid isn't recycled too soon is to keep
the postmasters handle open "long enough" (the postmaster already has a
handle there - it's just the pgstats process that doesn't have one).
RIght now we close the postmaster handle first (win32_removechild at ~
2086 in postmaster.c) and then fire off the message (CleanupBackend at
~2239).
//Magnus