Re: [PATCH] reclaim_child_processes in 1.3.x

["Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU>]

>All the other changes are just to correct the
>comments to be exact (because I'm anal).
>...
>
>-           case 1:     /*  16ms */
>-           case 2:     /*  82ms */
>+           case 1:     /*  16.384ms */
>+           case 2:     /*  65.536ms */
>                break;
>-           case 3:     /* 344ms */
>+           case 3:     /* 262.144ms */

Hmmm, it looks like you are just replacing cumulative numbers with
interval numbers in the comments, and adding decimal places to numbers
that are already estimates due to the per-instruction cycle time.

I wouldn't call that anal.

....Roy

Re: [PATCH] reclaim_child_processes in 1.3.x

[Ed Korthof <ed...@apache.org>]

On Sat, 30 Oct 1999, Roy T. Fielding wrote:

> >All the other changes are just to correct the
> >comments to be exact (because I'm anal).
> >...
> >
> >-           case 1:     /*  16ms */
> >-           case 2:     /*  82ms */
> >+           case 1:     /*  16.384ms */
> >+           case 2:     /*  65.536ms */
> >                break;
> >-           case 3:     /* 344ms */
> >+           case 3:     /* 262.144ms */
> 
> Hmmm, it looks like you are just replacing cumulative numbers with
> interval numbers in the comments, and adding decimal places to numbers
> that are already estimates due to the per-instruction cycle time.
> 
> I wouldn't call that anal.

the changes to the comments don't matter; i don't care all that much what
they read anyway.  but below them, you'll notice that apache sends
SIGKILL, and then attempts to reap the child processes immediately.  this
will generally fail, and as a consequence, apache will wait and additional
16.3 (or so) seconds, for no good reason (the children are dead within
milliseconds). that kinda sucks, if you're unlucky enough to hit it, and
my second patch does fix it.

so far as the comments go -- i wasn't aware that they were cumulative. the
last one was still wrong by that approach: it should be 22 by that count,
not 14 (since it's what i started with, and it bore no relationship to
reality, i figured that was the case with all of them).  and this means
that the second set of counts (after waitime gets reset) are inaccurate
either one way or the other.  the processor will be inaccurate, of course,
but the integer operations aren't, and i was indicating the requested wait
time at each stage.  but call it whatever you want.

please consider the part of the patch which makes apache wait a decent
period of time after sending sigkill, though -- it is worth fixing.

ed