> > Once upon a time, when I played with this stuff (I mostly use UNIX,
> > not Windows), I concluded to myself that HANDLE was
> process-local, and
> > that it was allocated. Meaning - it won't be re-used until
> you CloseHandle().
> > It's best then, to think of HANDLE as a opaque object.
> Regardless, of
> > whether it is process-local or not, until you run
> CloseHandle(), it is
> > yours to keep, and it won't be re-used.
>
> HANDLE is process local? That is worse then, because then
> there's no guarentee that each process will see a different
> identifier.
HANDLE is process local. What you need to do is run DuplicateHandle() on
it specifying it should "also be valid for process Y" (for which you
need a HANDLE opened, in this case the stats collector). This will give
you a new handle whichi s valid in the *target process*, but it is *not*
valid in your own process.
A quick look shows that pids appear to be reused quite fast on Windows
2000, but *not* on XP or 2003. Don't have any other versions around to
test.
AFAIK, the pid on unix is also only vaild while the process is running.
It's not likely to be reused quickly, which appears to be the same for
XP+ on win32.
> Do we have a plan C?
Well, first we need to know that this really *is* the problem. I'm
unsure if we've seen "proof" that this actually causes a real problem.
(It's certainly not the main issue with teh stats system on win32, which
is the fact that it crashes now and then)
How likely is it that the arrive-in-wrong-order really happens? And can
we do something about that one? (I assume the problem is that the
backend-die message is sent from postmaster, meaning that the die can
appear before the alive sent from the backend itself. What if we changed
it so we had one message sent from a backend doing a controlled shutdown
(99.9% of the time) and a different one when the postmaster picks up a
dead backend. And we apply the "dead counter" only to the messages from
the postmaster, and expire the record right away when we receive one
from a controlled shutdown (which would happen in-line with the
backend-start message)
//Magnus
//Magnus