cvs commit: apr/memory/unix apr_pools.c

[st...@apache.org]

stoddard    2002/11/11 20:24:51

  Modified:    .        CHANGES
               memory/unix apr_pools.c
  Log:
  Update free_proc_chain timeout algorithm from a static 3 second timeout
  to an exponentiallly growing timeout.
  
  PR: 7617
  
  Revision  Changes    Path
  1.355     +8 -0      apr/CHANGES
  
  Index: CHANGES
  ===================================================================
  RCS file: /home/cvs/apr/CHANGES,v
  retrieving revision 1.354
  retrieving revision 1.355
  diff -u -r1.354 -r1.355
  --- CHANGES	10 Nov 2002 08:35:15 -0000	1.354
  +++ CHANGES	12 Nov 2002 04:24:51 -0000	1.355
  @@ -1,4 +1,12 @@
   Changes with APR 0.9.2
  +  *) Update timeout algorithm in free_proc_chain. If a subprocess
  +     did not exit immediately, the thread would sleep for 3 seconds
  +     before checking the subprocess exit status again. In a very
  +     common case when the subprocess was an HTTP server CGI script,
  +     the CGI script actually exited a fraction of a second into the 3
  +     second sleep, which effectively limited the server to serving one 
  +     CGI request every 3 seconds across a persistent connection.
  +     [Bill Stoddard, Kai.Risku@arrak.fi]
   
     *) Update doxygen tags.  [Justin Erenkrantz]
   
  
  
  
  1.189     +36 -3     apr/memory/unix/apr_pools.c
  
  Index: apr_pools.c
  ===================================================================
  RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
  retrieving revision 1.188
  retrieving revision 1.189
  diff -u -r1.188 -r1.189
  --- apr_pools.c	22 Oct 2002 13:52:16 -0000	1.188
  +++ apr_pools.c	12 Nov 2002 04:24:51 -0000	1.189
  @@ -86,6 +86,15 @@
   #define BOUNDARY_INDEX 12
   #define BOUNDARY_SIZE (1 << BOUNDARY_INDEX)
   
  +/* 
  + * Timing constants for killing subprocesses
  + * There is a total 3-second delay between sending a SIGINT 
  + * and sending of the final SIGKILL.
  + * TIMEOUT_INTERVAL should be set to TIMEOUT_USECS / 64
  + * for the exponetial timeout alogrithm.
  + */
  +#define TIMEOUT_USECS    3000000
  +#define TIMEOUT_INTERVAL   46875
   
   /*
    * Allocator
  @@ -2031,6 +2040,7 @@
        */
       struct process_chain *pc;
       int need_timeout = 0;
  +    apr_time_t timeout_interval;
   
       if (!procs)
           return; /* No work.  Whew! */
  @@ -2071,9 +2081,32 @@
           }
       }
   
  -    /* Sleep only if we have to... */
  -    if (need_timeout)
  -        apr_sleep(apr_time_from_sec(3));
  +    /* Sleep only if we have to. The sleep algorithm grows
  +     * by a factor of two on each iteration. TIMEOUT_INTERVAL
  +     * is equal to TIMEOUT_USECS / 64.
  +     */
  +    if (need_timeout) {
  +        timeout_interval = TIMEOUT_INTERVAL;
  +        apr_sleep(timeout_interval);
  +    }
  +    while (need_timeout) {
  +        need_timeout = 0;
  +        /* check the status of the subprocesses */
  +        for (pc = procs; pc; pc = pc->next) {
  +            if (pc->kill_how == APR_KILL_AFTER_TIMEOUT &&
  +                apr_proc_wait(pc->pid, NULL, NULL, APR_NOWAIT) != APR_CHILD_NOTDONE)
  +                pc->kill_how = APR_KILL_NEVER;	/* subprocess has exited */
  +            else
  +                need_timeout = 1;		/* subprocess is still active */
  +        }
  +        if (need_timeout) {
  +            apr_sleep(timeout_interval);
  +            timeout_interval *= 2;
  +            if (timeout_interval >= TIMEOUT_USECS) {
  +                break;
  +            }
  +        }
  +    }
   
       /* OK, the scripts we just timed out for have had a chance to clean up
        * --- now, just get rid of them, and also clean up the system accounting