Re: [PATCH2] Re: Seg fault: race conditions in mod_mem_cache.c

[Jean-Jacques Clar]

I share your enjoyment.
Should I then go ahead and commit my patch to the 2.1 tree?Thanks,
JJ>>> [EMAIL PROTECTED] 09/14/04 3:41 PM >>>
Jean-Jacques Clar wrote:>  >Can you help me/us understand the following a little better?  > Let's look at al the cases where the cleanup function is called or the > object is accessed:> _The cleanup bit could only be set under the protection of the global > mutex_. This is critical.Thanks for the summary.  This helps a lot.> _open_entity()_>   mutex is locking access to object. The object is still in cache which > implies that>   the cleanup bit is not set, refcount is then incremented preventing > cleanup,>   and pool cleanup is registered before releasing the lock.Bill S. told me that open_entity() is the normal find function.  I didn't realize it was mutexed before.  Just thought other cache newbies might want to know.> Am I the only one having an increase in brain pulsations?No.  But I enjoy this kind of stuff.  Most of my increased pulsations are due to not looking at mod_mem_cache before.Greg

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[William A. Rowe, Jr.]

At 01:30 PM 9/14/2004, Joshua Slive wrote:

>On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
>>I'm trying to understand what other anomalies you mean between
>>Unix and Win32, they aren't that dis-similar.
>
>I was mainly refering to the big block of mpm-control directives near the top.
>
>But I like the suggestion of getting rid of almost all of that (besides some basic 
>things like MaxClients) and not discriminating against non-unix mpms.

I'm actually thinking that httpd-mpm.conf would include -all- of
the performance characteristics and server resources (e.g. the
switchboard and other mechanical tools) for running the server.
Existing directives I'd suggest (beyond the big-per-mpm block :-)
include the following (and don't include enablesendfile/mmap etc
because those are filesystem dependant and can vary by  block)
but only one-mpm-per-flavor of the .conf files...



  52#
  53# The accept serialization lock file MUST BE STORED ON A LOCAL 
DISK.
  54#


  55 
fielding
  1.45 #
  56#


  57 striker   1.1  #LockFile @rel_logfiledir@/accept.lock


  58 
fielding
  1.45 #
  59#


  60 striker   1.1  
  61#
  62# ScoreBoardFile: File used to store internal server process 
information.
  63# If unspecified (the default), the scoreboard will be stored in an
  64# anonymous shared memory segment, and will be unavailable to 
third-party
  65# applications.
  66# If specified, ensure that no two invocations of Apache share the 
same
  67# scoreboard file. The scoreboard file MUST BE STORED ON A LOCAL 
DISK.
  68#


  69 
fielding
  1.45 #
  70#


  71 striker   1.1  #ScoreBoardFile @rel_logfiledir@/apache_runtime_status


  72 
fielding
  1.45 #
  73#


  74 striker   1.1  
  75
  76#
  77# PidFile: The file in which the server should record its process
  78# identification number when it starts.
  79#
  80


  81 
jerenkrantz
 1.2  PidFile @rel_runtimedir@/httpd.pid


  82 striker 1.1  
  83  
  84  #
  85  # Timeout: The number of seconds before receives and sends time 
out.
  86  #
  87  Timeout 300
  88  
  89  #
  90  # KeepAlive: Whether or not to allow persistent connections 
(more than
  91  # one request per connection). Set to "Off" to deactivate.
  92  #
  93  KeepAlive On
  94  
  95  #
  96  # MaxKeepAliveRequests: The maximum number of requests to allow
  97  # during a persistent connection. Set to 0 to allow an unlimited 
amount.
  98  # We recommend you leave this number high, for maximum 
performance.
  99  #
 100  MaxKeepAliveRequests 100
 101  
 102  #
 103 striker 1.1  # KeepAliveTimeout: Number of seconds to wait for the next 
request from the
 104  # same client on the same connection.
 105  #
 106  KeepAliveTimeout 15
 107  
 108  ##
 109  ## Server-Pool Size Regulation (MPM specific)
 110  ## 
 111  
 112  # prefork MPM
 113  # StartServers: number of server processes to start
 114  # MinSpareServers: minimum number of server processes which are 
kept spare
 115  # MaxSpareServers: maximum number of server processes which are 
kept spare
 116  # MaxClients: maximum number of server processes allowed to start
 117  # MaxRequestsPerChild: maximum number of requests a server 
process serves
 118  


 119 
wsanchez
1.28 StartServers  5
 120  MinSpareServers   5
 121  MaxSpareServers  10
 122  MaxClients  150
 123  MaxRequestsPerChild   0


 124 striker 1.1  
 125  
 126  # worker MPM
 127  # StartServers: initial number

Re: [PATCH2] Re: Seg fault: race conditions in mod_mem_cache.c

[Greg Ames]

Jean-Jacques Clar wrote:
 >Can you help me/us understand the following a little better?  

Let's look at al the cases where the cleanup function is called or the 
object is accessed:
_The cleanup bit could only be set under the protection of the global 
mutex_. This is critical.
Thanks for the summary.  This helps a lot.
_open_entity()_
  mutex is locking access to object. The object is still in cache which 
implies that
  the cleanup bit is not set, refcount is then incremented preventing 
cleanup,
  and pool cleanup is registered before releasing the lock.
Bill S. told me that open_entity() is the normal find function.  I didn't 
realize it was mutexed before.  Just thought other cache newbies might want to 
know.

Am I the only one having an increase in brain pulsations?
No.  But I enjoy this kind of stuff.  Most of my increased pulsations are due to 
not looking at mod_mem_cache before.

Greg

Apache and CLASSPATH

[Zhi Qing Wu]

Hello,

I met a strange error when I developed a module for
Apache.

Since I would use gcj in writing the module, I wrote
two test programs (a JAVA program and a C program, the
C program calls the Java class, see the attachments
java2.cpp and Sigclass.java, ) before writing the
module. I compiled two test programs with gcc and
javac
(Main procedures:
   gcc java2.cpp -o java2 -lgcj -lstdc++
   javac single/Sigclass.java
)
and set CLASSPATH to the path of Sigclass.class before
running the C program. There are no errors in
compilation and execution. Its output is correct.

However, if I copied main code in the C program to the
apache module (wrote in GCJ C, no errors occur in
compilation, see mod_permis.cpp) and ran the apache
without changing CLASSPATH.

An error occurs in the error_log of the apache:

Unhandled Java exception:
java.lang.ClassNotFoundException: single.Sigclass not
found in
[file:/home/zhiqing/make/example3, file:./, core:/]


The path "file:/home/zhiqing/make/example3" is the
CLASSPATH for Sigclass. It is strange that the
computer can not find the class in the path.

Someone told me that after Apache is started, the path
of the file will be mapped to an Internet address,
which probably causes the CLASSPATH invalid. Some
parameters of Apache may also have influence on the
CLASSPATH.

I wonder if it is possible to change the CLASSPATH or
relevant parameters (or environment variables) of
Apache to get rid of the error.

The Apache in my computer is version 1.3.29. The
Apache and the C program are compiled with gcc 3.3.2.

Any advice or suggestion would be appreciated.

Zhi Qing





___ALL-NEW Yahoo! Messenger - 
all new features - even more fun!  http://uk.messenger.yahoo.com

java2.cpp
Description: java2.cpp


Sigclass.java
Description: Sigclass.java


mod_permis.cpp
Description: mod_permis.cpp

Re: [PATCH2] Re: Seg fault: race conditions in mod_mem_cache.c

[Jean-Jacques Clar]

>Can you help me/us understand the following a little better?  If it is possible >for two threads to simultaneously to have the same obj pointer and try to free >the object, what prevents a seg fault* due to:>- thread #1 gets a pointer to obj A, then looses its time slice due to the OS >scheduler before doing anything to the refcount or OBJ_CLEANUP_BIT>- thread #2 gets a pointer to obj A, refcount + OBJ_CLEANUP_BIT looks good, the >memory for obj A gets freed>- thread #1 wakes up and tries to access/update the refcount + OBJ_CLEANUP_BIT >in the freed memory
Thank you for looking.
Yes, you are right I forgot protecting one spot in remove_url(). I think all the other
ones are clean. Please jump in if you still see abnormalities or
have unanswered questions.
 
Let's look at al the cases where the cleanup function is called or the object is accessed:
The cleanup bit could only be set under the protection of the global mutex. This is critical.
 
create_entity()
  no worries, the refcount is created, set to 1, and the cleanup function is registered
open_entity()
  mutex is locking access to object. The object is still in cache which implies that
  the cleanup bit is not set, refcount is then incremented preventing cleanup,
  and pool cleanup is registered before releasing the lock.
remove_entity()
 mutex is locking access to object. This one is safe because the refcount must be
 at least 1, because open_entity() previously incremented it in the same thread
 The cleanup bit cannot be set before the lock is released.

store_body()
 This is a streamed response, the cleanup bit was set because of an ejection,
 but the refcount is at least one because of a previous access in the current 
 thread. No worries about decrement_refcount() bringing it to 0. We hold 
 the mutex and then can reset the cleanup bit on the current object and get
 rid of the tmp object.remove_url() - this one has a potential hole
 mutex is locking access to object. We have an object in the cache, it means that
 it was not previously removed which implies that the cleanup bit is not set and
 cannot be set on a different thread because of the lock. In this case, the later 
 call to cleanup_cache_object() could be a hole, I suggest doing that:
@@ -626,26 +621,13 @@
 obj = cache_find(sconf->cache_cache, key);    if (obj) {-    mem_cache_object_t *mobj;-    cache_remove(sconf->cache_cache, obj);-    mobj = (mem_cache_object_t *) obj->vobj;--    /* Refcount increment in this case MUST be made under - * protection of the lock - */-    apr_atomic_inc(&obj->refcount);-    if (obj) {-    obj->cleanup = 1;-    }+    cache_remove(sconf->cache_cache, obj);    +    memcache_cache_free(obj); } if (sconf->lock) { apr_thread_mutex_unlock(sconf->lock); }-    if (obj) {-    if (!apr_atomic_dec(&obj->refcount)) {-    cleanup_cache_object(obj);-    }-    } return OK; } Am I the only one having an increase in brain pulsations?


mod_mem_cache_race9.patch
Description: Binary data

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Joshua Slive]

On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
I'm trying to understand what other anomalies you mean between
Unix and Win32, they aren't that dis-similar.
I was mainly refering to the big block of mpm-control directives near the 
top.

But I like the suggestion of getting rid of almost all of that (besides 
some basic things like MaxClients) and not discriminating against non-unix 
mpms.

We have httpd-std.conf.in and ssl-std.conf.in, why not break
some of these more lengthy 'passages' into their very own
includes?  First and foremost, httpd-intl.conf.in - this
would take tons of lines across and leave a couple lines
Honestly, I prefer the one-config format, because I think it is easier for 
the new user to find what is going on if they know everything is in one 
file.  But this is a situation where personal preferences will vary.

But I have a compromise suggestion (based on Manoj's idea).  What about a 
conf/examples/ directory that would contain a bunch of little files with 
config snipets (like international.conf.in, proxy.conf.in, 
vhosts.conf.in).  Given the name of the directory, I would expect people 
to either copy-paste the stuff in httpd.conf or move the file before 
Include'ing it.  I wouldn't provide commented-out Include directives for 
these files.

Joshua.

Re: cvs commit: httpd-2.0/modules/proxy proxy_ajp.c

[Mladen Turk]

[EMAIL PROTECTED] wrote:
jorton  2004/09/14 10:29:36
  Modified:modules/proxy proxy_ajp.c
  Log:
  * modules/proxy/proxy_ajp.c (proxy_ajp_handler, proxy_ajp_canon): Drop
  ap_ prefix, declarations and make static.
Could you then do the same for proxy_http?
Both ap_proxy_http_canon and ap_proxy_http_handler should
be made static too.
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[William A. Rowe, Jr.]

At 10:21 AM 9/14/2004, Joshua Slive wrote:

>On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
>>A >30 KB default config, which nobody outside this circle here
>>really understands, isn't helpful - especially for beginners.
>
>I agree that the current config file is too big and ugly.  But let's be a little 
>careful here.  There needs to be a balance.  Detailed config files do help users 
>understand the capabilities of the server and make it much easier to activate 
>features.
>
>So I suggest we talk about specifics, rather than just trying to reduce the size.  
>For example:
>
>- Can we get rid of the non-unix mpm stuff from the default config. (Don't mean to 
>offend os/2 and beos (and possibly netware), but they are really superfluous and 
>confusing for most people.)

I'd vote -no-, with a caviat.  In our main example.conf, they should
be shown side-by-side.  E.g.

# Threaded Unix MPMs, e.g. Worker, require mod_cgid which forks
# it's own seperate process to dispatch the startup of cgi executables
#

LoadModule mod_cgid.conf


# Most non-threaded Unix MPMs, e.g. Prefork, and non-unix MPM's 
# use mod_cgi, where the httpd server process spawns the cgi
# process itself.
#

LoadModule mod_cgi.conf


... so any user trying to understand why they don't have mod_cgid
would run across this note and gasp "Ahhh!  That's what cgid means!"

I'm trying to understand what other anomalies you mean between
Unix and Win32, they aren't that dis-similar.

Honestly - this could be improved;




#ScoreBoardFile @rel_logfiledir@/apache_runtime_status



with some multiple-condition IfModule clause...


#ScoreBoardFile @rel_logfiledir@/apache_runtime_status


but that's neither here nor there.  In this case, you have an
exceptional case for Netware and a specific Unix MPM.  Are you
suggesting keep all the mpm exceptions for unix and ditch those
for the "Other" platforms?  Bleh.  But I have a productive
suggestion (I hope)...
>- Can we get rid of most of the AddLanguage/AddCharset directives?  They are a 
>constant source of bug reports, and I really can't imagine that many people use them 
>as-is.  (Do people really name their files index.html.utf32be.el?)

We have httpd-std.conf.in and ssl-std.conf.in, why not break
some of these more lengthy 'passages' into their very own
includes?  First and foremost, httpd-intl.conf.in - this
would take tons of lines across and leave a couple lines

# Internationalization - Character Sets and Languages
#
# mod_mime and mod_negotiation can serve alternate content, based 
# on the client's request headers and server content filenames.
# Uncomment this directive to serve multiple languages or character sets 
# based on the filename extention.
#
#Include httpd-intl.conf

We could do this to proxy and many other "complex" modules.  Best yet:

drop lines and lines of 'if this mpm we need that', and create
detailed and easy-to-read per-mpm subconfigs.  That would offer
us httpd-prefork.conf, httpd-worker.conf etc etc.  Only the
respective, installed mpm's conf would need to be present.  All 
such characteristics would move out to this file.

If that's too confusing, have these per-mpm subconfigs in the src,
but install only httpd-mpm.conf into every installation.

(Oh, for those who install all configs into /usr/etc or other common
conf locations, ssl-std.conf.in should really be installed as
httpd-ssl.conf to avoid ambiguity.)

But there is no reason to keep as many lines as we have in a single
config, multiple config files can be enormously helpful to the admin
to break apart these entirely separate aspects of configuration.
This would also reintroduce httpd-proxy.conf if someone wanted our
example (again) rather than one of many bad examples out there.

Bill

Re: cvs commit: httpd-2.0/modules/proxy proxy_ajp.c

[Mladen Turk]

Joe Orton wrote:
On Thu, Sep 09, 2004 at 07:56:31PM -, [EMAIL PROTECTED] wrote:
mturk   2004/09/09 12:56:31
 Modified:modules/proxy proxy_ajp.c
 Log:
 Add function protos so that -Wmissing-declarations doesn't complain.

Adding separate declarations within a .c file (rater than a header) to
fix such warnings is rarely correct: it looks like these should just be
made static? (in which case, no separate declaration is needed)
Well, yes.
It was just a copy/paste of the style used in the original code
present for years inside proxy_http :).
But you are correct, those are module private and should be static,
both inside proxy_ajp and proxy_http.
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: httpd-2.0/modules/proxy proxy_ajp.c

[Joe Orton]

On Thu, Sep 09, 2004 at 07:56:31PM -, [EMAIL PROTECTED] wrote:
> mturk   2004/09/09 12:56:31
> 
>   Modified:modules/proxy proxy_ajp.c
>   Log:
>   Add function protos so that -Wmissing-declarations doesn't complain.

Adding separate declarations within a .c file (rater than a header) to
fix such warnings is rarely correct: it looks like these should just be
made static? (in which case, no separate declaration is needed)

>   --- proxy_ajp.c 21 Aug 2004 19:27:24 -  1.17
>   +++ proxy_ajp.c 9 Sep 2004 19:56:30 -   1.18
>   @@ -20,6 +20,12 @@
>
>module AP_MODULE_DECLARE_DATA proxy_ajp_module;
>
>   +int ap_proxy_ajp_canon(request_rec *r, char *url);
>   +int ap_proxy_ajp_handler(request_rec *r, proxy_worker *worker,
>   + proxy_server_conf *conf,
>   + char *url, const char *proxyname, 
>   + apr_port_t proxyport);
>   +
>/*
> * Canonicalise http-like URLs.
> *  scheme is the scheme for the URL
>   
>   
>   

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Joshua Slive]

On Tue, 14 Sep 2004, Manoj Kasichainula wrote:
How about separating the "example" and "default" configs? Make the default 
config short, but provide an example config with all the meat that can be 
easily cut-and-pasted.
Or put richer examples in the docs.  We have been working on that a 
little.  Some of the module docs now come with a nice example config at 
the top which can be cut-pasted into httpd.conf (see 
mod_dav/mod_cache/mod_proxy/mod_defalte for examples).

For example, I think  lines in a config file are usually a bad 
idea, since the webserver should complain loudly if a needed module isn't 
present, instead of just ignoring the situation.
I've always been a strong supporter of that argument.  I frequently see 
people on the users list who try a directive and find that it doesn't work 
and they get no error message.  If they removed the  they would 
get a nice message telling them why it didn't work.

But there are several people who have argued strongly that they want the 
default config to work regardless of what modules people include in their 
build.

+1 to your proposal in the meantime (given my proposal above). I'd probably 
just get rid of all of the per-mpm stuff even. The mpms should have 
reasonable default values, so unless the admin needs to make a specific 
change, there should be no need for any of those directives in the default 
config.
+1!
If any changes in the defaults are necessary, then this would need to be 
2.1 only.  But I guess we are mostly talking about 2.1 in general anyway.

Joshua.

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Manoj Kasichainula]

On Tue, Sep 14, 2004 at 11:21:15AM -0400, Joshua Slive wrote:
On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
A >30 KB default config, which nobody outside this circle here
really understands, isn't helpful - especially for beginners.
I agree that the current config file is too big and ugly.  But let's be a 
little careful here.  There needs to be a balance.  Detailed config files 
do help users understand the capabilities of the server and make it much 
easier to activate features.
How about separating the "example" and "default" configs? Make the 
default config short, but provide an example config with all the meat 
that can be easily cut-and-pasted. 

For example, I think  lines in a config file are usually a bad 
idea, since the webserver should complain loudly if a needed module 
isn't present, instead of just ignoring the situation. Because the 
example config is serving as a sort of documentation for all these 
modules, but yet still has to work on whatever the user happens to 
build, it has to include those s, and it then encourages 
people to use them in a bad way.

- Can we get rid of the non-unix mpm stuff from the default config.  
(Don't mean to offend os/2 and beos (and possibly netware), but they 
are really superfluous and confusing for most people.)
+1 to your proposal in the meantime (given my proposal above). I'd 
probably just get rid of all of the per-mpm stuff even. The mpms should 
have reasonable default values, so unless the admin needs to make a 
specific change, there should be no need for any of those directives in 
the default config.

- Can we get rid of most of the AddLanguage/AddCharset directives?  
They are a constant source of bug reports, and I really can't imagine 
that many people use them as-is.  (Do people really name their files 
index.html.utf32be.el?)
+1

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Joshua Slive]

On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
A >30 KB default config, which nobody outside this circle here
really understands, isn't helpful - especially for beginners.
I agree that the current config file is too big and ugly.  But let's be a 
little careful here.  There needs to be a balance.  Detailed config files 
do help users understand the capabilities of the server and make it much 
easier to activate features.

So I suggest we talk about specifics, rather than just trying to reduce 
the size.  For example:

- Can we get rid of the non-unix mpm stuff from the default config. 
(Don't mean to offend os/2 and beos (and possibly netware), but they are 
really superfluous and confusing for most people.)

- Can we get rid of most of the AddLanguage/AddCharset directives?  They 
are a constant source of bug reports, and I really can't imagine that many 
people use them as-is.  (Do people really name their files 
index.html.utf32be.el?)

The above two changes alone would get rid of almost 200 lines.
In the same cycle we could remove the docs from the default distribution and
start distributing them officially as separate packages. (But we could
distribute a separate config snippet for the multilingual docs, which can
be included in the httpd.conf). The more translations we add, the less
applicable is it to include the whole doc tree.
+1
Joshua.

Re: [PATCH2] Re: Seg fault: race conditions in mod_mem_cache.c

[Greg Ames]

Jean-Jacques Clar wrote:
This one is working as expected on my server. I tested most
of the paths and it looks fine. Added comments to the previous
path. Will like some double-checking and feedback if possible.
Can you help me/us understand the following a little better?  If it is possible 
for two threads to simultaneously to have the same obj pointer and try to free 
the object, what prevents a seg fault* due to:

- thread #1 gets a pointer to obj A, then looses its time slice due to the OS 
scheduler before doing anything to the refcount or OBJ_CLEANUP_BIT
- thread #2 gets a pointer to obj A, refcount + OBJ_CLEANUP_BIT looks good, the 
memory for obj A gets freed
- thread #1 wakes up and tries to access/update the refcount + OBJ_CLEANUP_BIT 
in the freed memory

Thanks,
Greg
* or worse than a seg fault: the memory is re-used for something else, then we 
overwrite it.

Re: Shorten the default config and the distribution

[Greg Ames]

Paul Querna wrote:
On Tue, 2004-09-14 at 08:14 +0200, Andrà Malo wrote:
I'm rather for removing the whole crap from the default config and simplifiy
as much as possible.
A >30 KB default config, which nobody outside this circle here
really understands, isn't helpful - especially for beginners.

+1
+1.  I don't think it's appropriate to use the default config file for a manual 
or to advertise features.

Greg

Re: [PATCH] fix child reclaim timing

[Joe Orton]

On Fri, Aug 13, 2004 at 06:25:32PM -0400, Jeff Trawick wrote:
> this sounds a bit more sane to me for timing, as long as we can exit
> as soon as all children have exited:
> 
> shutdown + 0:
>   send SIGTERM
> shutdown + 4:
>   for each child still remaining, bitch to error log and send SIGTERM again
> shutdown + 8:
>   for each child still remaining, bitch to error log and send SIGTERM again
> shutdown + 12:
>   for each child still remaining, bitch to error log and send SIGKILL
> shutdown + 16:
>   for each child still remaining, bitch to error log, send SIGKILL again, 
> and exit anyway

I dropped the ball on this one... your proposed timing sounds OK to me
except I don't see any point in sending SIGKILL more than once. SIGTERM
can be ignored so sending that twice is semi-justified, but SIGKILL is
always fatal.

So how does this this look, it's slightly more complicated than I'd have
liked, but that is to mainly to ensure that it will never wait more than
a second between waitpid() calls:

The logic in handling the 'terminate' argument really dates to 1.3 and
doesn't make much sense any more (it only ever sends SIGTERM not
SIGHUP), not sure what to do about that.

Index: server/mpm_common.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm_common.c,v
retrieving revision 1.121
diff -u -r1.121 mpm_common.c
--- server/mpm_common.c 14 Aug 2004 10:49:43 -  1.121
+++ server/mpm_common.c 14 Sep 2004 11:08:48 -
@@ -62,21 +62,31 @@
 void ap_reclaim_child_processes(int terminate)
 {
 int i;
-long int waittime = 1024 * 16;  /* in usecs */
 apr_status_t waitret;
 int tries;
 int not_dead_yet;
 int max_daemons;
+#define NUMWAITS (7)
+static const int timing[NUMWAITS] = {
+16, 64, 256, 768, 1000, 1000, 1000
+};
 
 ap_mpm_query(AP_MPMQ_MAX_DAEMON_USED, &max_daemons);
 
-for (tries = terminate ? 4 : 1; tries <= 9; ++tries) {
-/* don't want to hold up progress any more than
- * necessary, but we need to allow children a few moments to exit.
- * Set delay with an exponential backoff.
- */
-apr_sleep(waittime);
-waittime = waittime * 4;
+/* Algorithm as follows: step 1 omitted if terminate is true:
+ * 1. spend ~4 seconds wait()ing for children, 
+ * 2. log an error and send a SIGTERM to remaining children
+ * 3. spend another ~4 seconds wait()ing for children.
+ * 4. log an error and send a SIGTERM to remaining children
+ * 5. spend another ~4 seconds wait()ing for children.
+ * 6. log an error and send a SIGKILL to remaining children
+ * 7. after 64ms wait() for remaining children
+ *and log an error for each remaining live child
+ */
+for (tries = terminate ? NUMWAITS : 0;
+ tries <= NUMWAITS * 3 + 1; ++tries) {
+
+apr_sleep(timing[tries % NUMWAITS] * 1000);
 
 /* now see who is done */
 not_dead_yet = 0;
@@ -95,16 +105,8 @@
 }
 
 ++not_dead_yet;
-switch (tries) {
-case 1: /*  16ms */
-case 2: /*  82ms */
-case 3: /* 344ms */
-case 4: /*  16ms */
-break;
-
-case 5: /*  82ms */
-case 6: /* 344ms */
-case 7: /* 1.4sec */
+
+if (tries == NUMWAITS || tries == NUMWAITS * 2) {
 /* ok, now it's being annoying */
 ap_log_error(APLOG_MARK, APLOG_WARNING,
  0, ap_server_conf,
@@ -112,9 +114,7 @@
  "sending a SIGTERM",
  (long)pid);
 kill(pid, SIGTERM);
-break;
-
-case 8: /*  6 sec */
+} else if (tries == NUMWAITS * 3) {
 /* die child scum */
 ap_log_error(APLOG_MARK, APLOG_ERR,
  0, ap_server_conf,
@@ -132,9 +132,7 @@
  */
 kill_thread(pid);
 #endif
-break;
-
-case 9: /* 14 sec */
+} else if (tries == NUMWAITS * 3 + 1) {
 /* gave it our best shot, but alas...  If this really
  * is a child we are trying to kill and it really hasn't
  * exited, we will likely fail to bind to the port
@@ -145,7 +143,6 @@
  "could not make child process %ld exit, "
  "attempting to continue anyway",
  (long)pid);
-break;
 }
 }