of trying to take over scoreboard slots that aren't going to be released
(we could also be stalled while taking over slots if a thread in child
gracefully terminating is serving a long-running request)

update a comment describing the sicko state to remove any information
I'm not absolutely sure of


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94059 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94058 13f79535-47bb-0310-9956-ffa450edef68

1. rename ap_rset_content_type to ap_set_content_type
2. reverse the arguments to aligh with ap_set_content_length


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94057 13f79535-47bb-0310-9956-ffa450edef68

1. rename ap_rset_content_type to ap_set_content_type
2. reverse the arguments on the call to aligh with ap_set_content_length


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94056 13f79535-47bb-0310-9956-ffa450edef68

the admin regarding valid values for AcceptMutex. Should also
tell 'em what "default" actually maps to, but that can wait.

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94055 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94054 13f79535-47bb-0310-9956-ffa450edef68

The LIBPATH env var already must contain the path to lib/ in order to pick up
apr and apr-util.  If we install the core dll there as well, LIBPATH becomes
simpler.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94053 13f79535-47bb-0310-9956-ffa450edef68

possibly deal with a script that generates the protocol header.

PR:       8902, 8907, 9983


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94052 13f79535-47bb-0310-9956-ffa450edef68

this is friendlier to callers and r->content_type is const char *
too so it isn't harmful

this fixes a fatal compile error with AIX+xlc


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94051 13f79535-47bb-0310-9956-ffa450edef68

  No sense in opening this event when it's already opened in the parent.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94050 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94049 13f79535-47bb-0310-9956-ffa450edef68

  Here's the patch that really sucks.  old_listeners points to an array
  of apr_socket objects already destroyed by their cleanups, and in any
  case they now live in invalid memory.  Extend their lifetimes.

  This implies that the process pool grows on every restart for no good
  reason.  One possible solution is to let the old pconf survive until
  the new pconf is alive.  Another is to create the listeners in a subpool
  of process->pool, destroyed after the old_listeners are closed.

  Either which way, a better solution exists, but this closes the immediate
  bug.  [How haven't we been segfaulting in unix on restarts before this
  patch, gurus?]


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94048 13f79535-47bb-0310-9956-ffa450edef68

latest version of PCRE


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94047 13f79535-47bb-0310-9956-ffa450edef68

  More process lifetime changes, and simplify some ambigious cruft.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94046 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94045 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94044 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94043 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94042 13f79535-47bb-0310-9956-ffa450edef68

  Fix a few listener-related lifetime issues [they are created in the
  open logs phase, only once.]


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94041 13f79535-47bb-0310-9956-ffa450edef68

  The source of some ills ... there is no reason to keep going if the
  scoreboard exists.  I suspect this should be a general cleanup as well
  [at the end of ap_create_scoreboard.]  But calling ap_run_pre_mpm with
  the process->pool should take care of a clobbered scoreboard shm on
  graceful restart.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94040 13f79535-47bb-0310-9956-ffa450edef68

  The pre_mpm hook creates server-lifetime objects (or at least, for the
  generations across graceful restarts.)  They should use the process pool.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94039 13f79535-47bb-0310-9956-ffa450edef68

which included commits to RCS files with non-trunk default branches.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94037 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94033 13f79535-47bb-0310-9956-ffa450edef68

  When restarting [always graceful on Win32], we don't repeat pre_mpm
  (Unix doesn't, we shouldn't either.)  [Ryan Bloom]


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94032 13f79535-47bb-0310-9956-ffa450edef68

cleanly at graceful restart time.  This is a basic requirement of
reliable graceful restarts (the kind that won't drop connections).
This allows a future fix to make worker threads hang around until
they service all connections previously accepted by the listener
thread.

The old mechanism of doing a dummy connection to wake up the
listener thread in each old child process didn't work.  It didn't
guarantee that (in the main thread) the byte was read from the pod
and global variables were set before the listener thread grabbed
the connection.  It didn't guarantee that a child process in the
new generation didn't get some of the dummy connections.

Rather than burn extra syscalls adding a unique socket or pipe
to the poll set (and breaking single listen unserialized accept
in the same change), this uses a signal sent from the main thread
to the listener thread to break it out of the poll or accept.
(We don't worry about breaking it out of the optional mutex because
the child process holding the mutex will break out of poll/accept
and release the mutex, allowing a child blocked in the mutex to
get it.  Eventually all children blocked in the mutex will come
out.)

Since the listener thread now exits reliably, the main thread
joins it.

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94031 13f79535-47bb-0310-9956-ffa450edef68

it is still trying to create worker threads

previously, after a non-graceful restart followed by a terminate
you could see a bunch of log messages showing the parent repeatedly
sending SIGTERM and finally SIGKILL to one or more children...
with this change, the sequence of messages should stop very soon

add a comment to start_threads() describing a current problem


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94030 13f79535-47bb-0310-9956-ffa450edef68

filters during call to ap_rset_content_type()


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94028 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94027 13f79535-47bb-0310-9956-ffa450edef68

it is helpful to distinguish between a failure creating the
first thread (listener) vs. a failure creating one of n
worker threads


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94025 13f79535-47bb-0310-9956-ffa450edef68

the pod...  the child processes need to know that it isn't a graceful
termination and they shouldn't wait for old connections to finish


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94024 13f79535-47bb-0310-9956-ffa450edef68

Submitted by: Dale Ghent <daleg@elemental.org>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94023 13f79535-47bb-0310-9956-ffa450edef68

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94020 13f79535-47bb-0310-9956-ffa450edef68

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94019 13f79535-47bb-0310-9956-ffa450edef68

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94018 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94017 13f79535-47bb-0310-9956-ffa450edef68

now that it has an RFC. At the same time, I revamped a good chunk of
the name <-> number mapping code in http_protocol.c

* add M_FOO constants for the new RFC 3253 (DeltaV) methods. label
  where each of the builtin methods comes from.

* moved METHOD_NUMBER_FIRST/LAST from http_protocol.h into
  http_protocol.c since they weren't used anywhere else and they
  weren't namespace-protected.

* create register_one_method() and use it to insert all builtin
  methods (at _init() time) and extended methods into the registry.

* add a lookup_builtin_method() to quickly map a method name to a
  builtin method number.

* rebuild ap_method_number_of() to use the new lookup function.

* revamp ap_method_name_of() to use the registry to locate the name
  for any method number. add a pool argument (no callers in the core
  code needed to be updated)

* revamp make_allow() to deal with the new method numbers and all
  extended methods.

* in mod_dav, use the new method numbers rather than registering the
  DeltaV methods.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94015 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94014 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94013 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94012 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94011 13f79535-47bb-0310-9956-ffa450edef68