On Oct 26, 2007, at 8:13 AM, Jim Jagielski wrote:
sure; I'm lacking cycles at the moment to start looking through the
code for potential fallout; hope to start looking soon
I spent just a little bit of time, but the current code
has a mishmash of logic checking for pid == 0 or SERVER_DEAD
and sometimes both but not always. The constant assumption
is that a pid of 0 means no child. So from a cursory check,
this should be fixed anyway, and will also address the
current issue as well.
btw, the only fallout I saw from a quick check last night
dealt with mod_status on TPF where there is an express
section of code that wants to show the PIDs of the
"living dead":
if (score_record.status == SERVER_DEAD)
#ifdef TPF
if (kill(ps_record.pid, 0) == 0) {
/* on TPF show PIDs of the living
dead */
ap_rprintf(r,
"<b>Server %d-%d</b> (%d): %d|%lu|%
lu [",
i, (int) ps_record.generation,
(int)ps_record.pid, (int) conn_lres,
my_lres, lres);
} else
#endif /* TPF */
Note 2 things:
1. We don't bother to check if that is actually a "valid" pid,
that is, a pid that belongs to us.
2. But we just just want to see if the process is still around
anyway.
To be honest, this looks weird to me since a bunch of the (unused) slots
with be SERVER_DEAD (which is 0) and with a pid of 0 so TPF appears
to handle this OK (I'm guessing the fact that TPF has no group
concept means its kill(0, 0) is different from Unix's)...
Recall that when we init the scoreboard anyway, we memset 0, so all
unused
slots are SERVER_DEAD and pid == 0.
