RE: [PATCH] remove some mutex locks in the worker MPM
it may also have to do with caching we were doing (mod_mem_cache crashed and burned, What version were you running? What was the failure? If you can give me enough info to debug the problem, I'll work on it. Bill
Re: cvs commit: httpd-2.0/modules/aaa mod_authn_dbm.c
* [EMAIL PROTECTED] wrote: nd 2002/12/31 20:08:26 Modified:modules/aaa mod_authn_dbm.c Log: add support for digest authentication to the authn_dbm module. The key is $user:$realm (perl speaking), the value is the MD5-hash, optionally followed by a colon and other garbage. hmm, although $user:$realm semantically _is_ the key, that causes the problem, that mod_authz_dbm won't support it (it currently doesn't support digest authentication anyway). What would be the best variant? - do some magic, i.e. if AuthType digest then use $user and $user:$realm as lookup key (in which order?) - make it configurable (additional argument to AuthDBMGroupFile?) - consider a provider mechanism for authorization modules, too? My favourites are the second or third option :) better ideas? nd -- die (eval q-qq:Just Another Perl Hacker :-) # André Malo, http://www.perlig.de/ #
[PATCH 2] Remove mutex locks from worker MPM
Here's an updated patch for the worker MPM. It contains the pool-recycling changes from my first patch yesterday, plus a (mostly) mutex-free implementation of the idle worker count. The logic for this latest change is somewhat more complicated, so I'd appreciate test results and/or code review from anyone with the time and interest to check for race conditions. Thanks, Brian
[PATCH 2] Remove mutex locks from worker MPM
Here's an updated patch for the worker MPM. It contains
the pool-recycling changes from my first patch yesterday,
plus a (mostly) mutex-free implementation of the idle worker
count.
The logic for this latest change is somewhat more complicated,
so I'd appreciate test results and/or code review from anyone
with the time and interest to check for race conditions.
Thanks,
Brian
Index: server/mpm/worker/fdqueue.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/worker/fdqueue.c,v
retrieving revision 1.23
diff -u -r1.23 fdqueue.c
--- server/mpm/worker/fdqueue.c 2 Aug 2002 17:37:52 - 1.23
+++ server/mpm/worker/fdqueue.c 1 Jan 2003 18:57:56 -
@@ -57,6 +57,12 @@
*/
#include fdqueue.h
+#include apr_atomic.h
+
+typedef struct recycled_pool {
+apr_pool_t *pool;
+struct recycled_pool *next;
+} recycled_pool;
struct fd_queue_info_t {
int idlers;
@@ -64,19 +70,27 @@
apr_thread_cond_t *wait_for_idler;
int terminated;
int max_idlers;
-apr_pool_t**recycled_pools;
-int num_recycled;
+recycled_pool *recycled_pools;
};
static apr_status_t queue_info_cleanup(void *data_)
{
fd_queue_info_t *qi = data_;
-int i;
apr_thread_cond_destroy(qi-wait_for_idler);
apr_thread_mutex_destroy(qi-idlers_mutex);
-for (i = 0; i qi-num_recycled; i++) {
-apr_pool_destroy(qi-recycled_pools[i]);
+
+/* Clean up any pools in the recycled list */
+for (;;) {
+struct recycled_pool *first_pool = qi-recycled_pools;
+if (first_pool == NULL) {
+break;
+}
+if (apr_atomic_casptr((qi-recycled_pools), first_pool-next,
+ first_pool) == first_pool) {
+apr_pool_destroy(first_pool-pool);
+}
}
+
return APR_SUCCESS;
}
@@ -98,9 +112,7 @@
if (rv != APR_SUCCESS) {
return rv;
}
-qi-recycled_pools = (apr_pool_t **)apr_palloc(pool, max_idlers *
- sizeof(apr_pool_t *));
-qi-num_recycled = 0;
+qi-recycled_pools = NULL;
qi-max_idlers = max_idlers;
apr_pool_cleanup_register(pool, qi, queue_info_cleanup,
apr_pool_cleanup_null);
@@ -114,24 +126,53 @@
apr_pool_t *pool_to_recycle)
{
apr_status_t rv;
-rv = apr_thread_mutex_lock(queue_info-idlers_mutex);
-if (rv != APR_SUCCESS) {
-return rv;
-}
-AP_DEBUG_ASSERT(queue_info-idlers = 0);
-AP_DEBUG_ASSERT(queue_info-num_recycled queue_info-max_idlers);
+int prev_idlers;
+
+/* If we have been given a pool to recycle, atomically link
+ * it into the queue_info's list of recycled pools
+ */
if (pool_to_recycle) {
-queue_info-recycled_pools[queue_info-num_recycled++] =
-pool_to_recycle;
+struct recycled_pool *new_recycle;
+new_recycle = (struct recycled_pool *)apr_palloc(pool_to_recycle,
+ sizeof(*new_recycle));
+new_recycle-pool = pool_to_recycle;
+for (;;) {
+new_recycle-next = queue_info-recycled_pools;
+if (apr_atomic_casptr((queue_info-recycled_pools),
+ new_recycle, new_recycle-next) ==
+new_recycle-next) {
+break;
+}
+}
}
-if (queue_info-idlers++ == 0) {
-/* Only signal if we had no idlers before. */
-apr_thread_cond_signal(queue_info-wait_for_idler);
+
+/* Atomically increment the count of idle workers */
+for (;;) {
+prev_idlers = queue_info-idlers;
+if (apr_atomic_cas((queue_info-idlers), prev_idlers + 1, prev_idlers)
+== prev_idlers) {
+break;
+}
}
-rv = apr_thread_mutex_unlock(queue_info-idlers_mutex);
-if (rv != APR_SUCCESS) {
-return rv;
+
+/* If this thread just made the idle worker count nonzero,
+ * wake up the listener. */
+if (prev_idlers == 0) {
+rv = apr_thread_mutex_lock(queue_info-idlers_mutex);
+if (rv != APR_SUCCESS) {
+return rv;
+}
+rv = apr_thread_cond_signal(queue_info-wait_for_idler);
+if (rv != APR_SUCCESS) {
+apr_thread_mutex_unlock(queue_info-idlers_mutex);
+return rv;
+}
+rv = apr_thread_mutex_unlock(queue_info-idlers_mutex);
+if (rv != APR_SUCCESS) {
+return rv;
+}
}
+
return APR_SUCCESS;
}
@@ -139,34 +180,62 @@
apr_pool_t **recycled_pool)
{
apr_status_t rv;
+
*recycled_pool = NULL;
-rv = apr_thread_mutex_lock(queue_info-idlers_mutex);
-if (rv != APR_SUCCESS) {
-return rv;
-}
-AP_DEBUG_ASSERT(queue_info-idlers = 0);
-while ((queue_info-idlers == 0) (!queue_info-terminated)) {
-
Re: [PATCH 2] Remove mutex locks from worker MPM
Hey Brian, your patch seems to have been eaten by gremlins :-( -Thom * Brian Pane ([EMAIL PROTECTED]) wrote : Here's an updated patch for the worker MPM. It contains the pool-recycling changes from my first patch yesterday, plus a (mostly) mutex-free implementation of the idle worker count. The logic for this latest change is somewhat more complicated, so I'd appreciate test results and/or code review from anyone with the time and interest to check for race conditions. Thanks, Brian
Re: [PATCH 2] Remove mutex locks from worker MPM
On Wed, 2003-01-01 at 11:00, Thom May wrote: Hey Brian, your patch seems to have been eaten by gremlins :-( Sorry about that, the send and attachment buttons on this email program are right next to each other. :-) I just re-sent with the patch attached. One other thing I should note: there are a couple of platforms where you'll get better results by configuring with --enable-nonportable-atomics=yes before building: * Solaris on SPARC (as long as you don't need to run on pre-v8plus systems) * Linux on x86 (as long as you don't need to run on 386 or earlier) For these architectures, --enable-nonportable-atomics=yes is needed to make APR use the opcodes for atomic CAS, rather than emulating them with mutexes. Brian
mod_mem_cache bad for large/busy files (Was: [PATCH] remove some mutex locks in the worker MPM)
Apache 2.0.43, Solaris 8, Sun E220R, 4 gig memory, gig ethernet. We tried both Sun forte and gcc compilers. The problem was mod_mem_cache was just way too resource intensive when pounding on a machine that hard, trying to see if everything would fit into the cache... cpu/mutexes were very high, especially memory was out of control (we had many very large files, ranging from half dozen to two dozen megs, the most popular of those were what we really wanted cached), and we were running several hundred concurrent connections at once. Maybe a new cache loading/hit/removal algorithm that works better for many hits to very large files would solve it I dunno. We finally settled on listing out some of the most popular files out in the httpd.conf file for mod_file_cache, but that presents a management problem as what's most popular changes. It would have been nicer if apache could auto-sense the most popular files. Also it seems mod_file_cache has a file size limit but at least we got enough in there the disk wasn't bottlenecking anymore... Dave - Original Message - From: Bill Stoddard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 01, 2003 6:38 AM Subject: RE: [PATCH] remove some mutex locks in the worker MPM it may also have to do with caching we were doing (mod_mem_cache crashed and burned, What version were you running? What was the failure? If you can give me enough info to debug the problem, I'll work on it. Bill
Re: mod_mem_cache bad for large/busy files (Was: [PATCH] removesome mutex locks in the worker MPM)
On Wed, 2003-01-01 at 11:26, David Burry wrote: Apache 2.0.43, Solaris 8, Sun E220R, 4 gig memory, gig ethernet. We tried both Sun forte and gcc compilers. The problem was mod_mem_cache was just way too resource intensive when pounding on a machine that hard, trying to see if everything would fit into the cache... cpu/mutexes were very high, especially memory was out of control (we had many very large files, ranging from half dozen to two dozen megs, the most popular of those were what we really wanted cached), and we were running several hundred concurrent connections at once. Maybe a new cache loading/hit/removal algorithm that works better for many hits to very large files would solve it I dunno. I know of a couple of things that cause mutex contention in mod_mem_cache: * Too many malloc/free calls This may be easy to improve. Currently, mod_mem_cache does many mallocs for strings and nested objects within a cache object. We could probably malloc one big buffer containing enough space to hold all those objects. * Global lock around the hash table and priority queue This will be difficult to fix. It's straightforward to provide thread-safe, highly-concurrent access to a hash table (either use a separate lock for each hash bucket, or use atomic-CAS based pointer swapping when traversing the hash chains). The problem is that we need to read/update the priority queue as part of the same transaction in which we read/update the hash table, which leaves us stuck with a big global lock. If we could modify the mod_mem_cache design to not require the priority queue operations and the hash table operations to be done as part of the same critical region, I think that would open up the door to some major concurrency improvements. But I'm not sure whether that's actually possible. Brian
Re: [PATCH] remove hardcoding of suexec log location
The log is generated from the suexec binary, not httpd, right? Then we can't use a directive to control it and it needs to be hardcoded for safety. The patch below to make it relative to the logfiledir at configure-time makes sense. +1 -aaron On Tuesday, December 31, 2002, at 04:41 AM, David Reid wrote: Maybe we should have another directive for the suexec log? But I agree it shouldn't be hardcoded. david - Original Message - From: Thom May [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 31, 2002 11:39 AM Subject: [PATCH] remove hardcoding of suexec log location This is to fix PR 15713 suexec-logfile has hardcoded default instead of being placed in --logfiledir I'm not sure it's right, though, since I'm not sure of the status of suexec on win32/other places where ap_config_layout.h isn't available. -Thom Index: support/suexec.h === RCS file: /home/cvspublic/httpd-2.0/support/suexec.h,v retrieving revision 1.7 diff -u -u -r1.7 suexec.h --- support/suexec.h 27 Sep 2002 23:53:04 - 1.7 +++ support/suexec.h 30 Dec 2002 12:10:17 - @@ -62,6 +62,12 @@ #define _SUEXEC_H /* + * Include ap_config_layout so we can work out where the default htdocsdir + * and logsdir are. + */ +#include ap_config_layout.h + +/* * HTTPD_USER -- Define as the username under which Apache normally * runs. This is the only user allowed to execute * this program. @@ -117,7 +123,7 @@ * debugging purposes. */ #ifndef AP_LOG_EXEC -#define AP_LOG_EXEC /usr/local/apache2/logs/cgi.log /* Need me? */ +#define AP_LOG_EXEC DEFAULT_EXP_LOGFILEDIR /suexec_log /* Need me? */ #endif /* @@ -126,7 +132,7 @@ * that can be used for suEXEC behavior. */ #ifndef AP_DOC_ROOT -#define AP_DOC_ROOT /usr/local/apache2/htdocs +#define AP_DOC_ROOT DEFAULT_EXP_HTDOCSDIR #endif /*
Re: [PATCH] remove some mutex locks in the worker MPM
The patch looks good at first glance. Have you done any testing to see how much it improves performance (on UP and MP machines) and if it has any effect when APR is build with generic atomics? -aaron On Tuesday, December 31, 2002, at 05:30 PM, Brian Pane wrote: I'm working on replacing some mutex locks with atomic-compare-and-swap based algorithms in the worker MPM, in order to get better concurrency and lower overhead. Here's the first change: take the pool recycling code out of the mutex-protected critical region in the queue_info code. Comments welcome... Next on my list is the code that synchronizes the idle worker count. I think I can eliminate the need to lock a mutex except in the special case where all the workers are busy.
Re: Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)
On Wed, Jan 01, 2003 at 10:43:18PM +, Thom May wrote: * Aaron Bannert ([EMAIL PROTECTED]) wrote : The log is generated from the suexec binary, not httpd, right? Then we can't use a directive to control it and it needs to be hardcoded for safety. The other issue for suexec is mass vhosting; this has somewhat different needs, and mostly results in ISPs patching suexec to do what they need, which seems like a bad thing unless the ISPs can sucessfully audit the resulting codebase. It's a very bad thing, because in 99.99% of cases it's completely unneccessary! The real problem is that mass vhosting generates large numbers of document roots; covering them all with one docroot compiled into suexec can result in, eg, /home being set as the docroot. /home is a very bad docroot, and I'd question the reasons behind hosting virtual hosts in /home, the usual reason is for FTP/shell access, but that can be solved with symlinks, or just setting the homedir elsewhere. In general for sites with virtual hosts that need SuexecUserGroup I set docroot to $prefix/vhosts, and put them all in there, problem solved :) Compiling with a list of document roots sounds good in principal, but we on average add a site an hour, recompiling suexec every hour isn't particularily practical, and the configure args would be several miles long :-) Every hour! Youch, but are you adding a VirtualHost and restarting apache every hour ? If not, how are you mapping those URI's and how are you associating them with a username/group ? If you are, and if this is common, there is some limited justification for getting suexec to support such situations. But against that is the reality that in order to support it suexec would have to parse every single configuration file, determine which VirtualHost blocks have SuexecUserGroup directives and remember their Docroot, that's an awful lot of work for something that's exec'd for every CGI and is security critical. As has been pointed out, if people really want to use /home, then mod_rewrite [+mod_proxy +mod_userdir] is probably a much better way to go. It seems to me that a different binary would be the best path; suexec-mass-vhost or whatever. it needs to be able to work correctly with mod_vhost_alias, and it potentially needs to be able to take docroot arguments from httpd.conf. suexec will never work correctly with vhost_alias, or mod_rewrite :) How would you tell it what username/group to use ? The whole point of these approaches to virtual hosting is to simplify a long list of domains into one ruleset. That's not compatible with having a different username/group for each one. Then again, if you wanted to have them all run as the same user, there've been (now incomplete) patches to allow SuexecUserGroup to work in Directory blocks, see: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9038 for one. Aswell as the mass vhost stuff there's still the outstanding issue of making SHELLCMD work with suexec , see: http://redbrick.dcu.ie/~colmmacc/patches/proc.patch from the STATUS. Also maybe change the default permissions of the suexec binary to 4750 and advise people to chgrp it to the group httpd runs as. -- [EMAIL PROTECTED]PubKey: [EMAIL PROTECTED] Web: http://devnull.redbrick.dcu.ie/
Re: cvs commit: httpd-2.0/modules/filters mod_deflate.c
--On Wednesday, January 1, 2003 8:31 PM + [EMAIL PROTECTED] wrote:
@@ -239,6 +256,11 @@
apr_bucket_brigade *bb, *proc_bb;
} deflate_ctx;
+#define LeaveNote(type, value) \
+if (c-note##type##Name) \
+apr_table_setn(r-notes, c-note##type##Name, \
+ (ctx-stream.total_in 0) ? (value) :
-)
We don't use mixed case for any definitions, and we require braces at
all times, and for macros longer than one line, we wrap it with a do
{} while (0) clause so that some compilers are a bit happier.
So, I would probably suggest something like:
#define leave_note(type, value) \
do { \
if (c-note##type##Name) { \
apr_table_setn(r-notes, c-note##type##Name, \
(ctx-stream.total_in 0) ? (value) : -) \
} \
} while (0)
+LeaveNote(Input, apr_off_t_toa(r-pool,
ctx-stream.total_in));
+LeaveNote(Output, apr_off_t_toa(r-pool,
ctx-stream.total_out));
+LeaveNote(Ratio, apr_itoa(r-pool, (int)
+ (ctx-stream.total_out *
100 / ctx-stream.total_in)));
All of that said, I'm not really sure this code even merits being a
macro. I'd rather see the conditional execution clear at the scope
where LeaveNote is called rather than hidden in its definition.
Yeah, it's slightly repetitive, but I'm not really buying what the
macro is getting us here. IMHO, there should be an extremely high bar
to creating a macro. -- justin
Re: cvs commit: httpd-2.0/modules/aaa mod_authn_dbm.c
--On Wednesday, January 1, 2003 7:21 PM +0100 André Malo [EMAIL PROTECTED] wrote: hmm, although $user:$realm semantically _is_ the key, that causes the problem, that mod_authz_dbm won't support it (it currently doesn't support digest authentication anyway). What would be the best variant? - do some magic, i.e. if AuthType digest then use $user and $user:$realm as lookup key (in which order?) - make it configurable (additional argument to AuthDBMGroupFile?) - consider a provider mechanism for authorization modules, too? My favourites are the second or third option :) better ideas? I would probably implement choice one for now. ($user:$realm first, then $user.) Note that I always planned on adding a provider mechanism for authorization modules, but somehow got sidetracked on that. But, yeah, that should definitely happen, too. =) (Choice 2 doesn't make a whole lot of sense to me.) -- justin
[STATUS] (apache-1.3) Wed Jan 1 23:45:14 EST 2003
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/10/31 05:57:52 $] Release: 1.3.28-dev: In development 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: Pine.LNX.4.21.0102102350060.6815-20@desktop Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia [EMAIL PROTECTED]' patch to allow DirectoryIndex to refer to URIs for non-static resources. MID: [EMAIL PROTECTED] Status: Ken +1 (on concept), Lars +1 (on concept) * Brian Havard's patch
[STATUS] (httpd-2.0) Wed Jan 1 23:45:22 EST 2003
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2002/12/03 18:26:44 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on TODO or XXX and see what's there CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj +0: Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * There is a bug in how we sort some hooks, at least the pre-config hook. The first time we call the hooks, they are in the correct order, but the second time, we don't sort them correctly. Currently, the modules/http/config.m4 file has been renamed to modules/http/config2.m4 to work around this problem, it should moved back when this is fixed. OtherBill offers that this is a SERIOUS problem. We do not sort correctly by the ordering arguments passed to the register hook functions. This was proven when I reordered the open_logs hook to attempt to open the error logs prior to the access logs. Possibly the entire sorting code needs to be refactored. * pipes deadlock on all platforms with limited pipe buffers (e.g. both Linux and Win32, as opposed to only Win32 on 1.3). The right solution is either GStein's proposal for a CGI Brigade, or OtherBill's proposal for Poll Buckets for Polling Filter Chains. Or maybe both :-) * All handlers should always send content down even if r-header_only is set. If not, it means that the HEAD requests don't generate the same headers as a GET which is wrong. * HP/UX 10.20: compile breakage in APR. Looks like it should be easy to fix, probably just some extraneous #include's that are fouling things up. PR: 9457 Jeff: See my reply and patch in the PR (and previous commit to stop using pipe as a field name). If patch is committed, we should be okay. I'll wait to see if the user tests the patch. Update by Jeff 20020722: I got an account on HP 10.20. It looks like some of the APR thread detection is screwed up. If we find pthread.h but we can't compile the pthread test program we still think we can use threads. For that reason, the patch I posted to the PR won't work as-is since a failed compile of the test program means nothing. * exec cmd and suexec arg-passing enhancements Status: Patches proposed Message-ID: [EMAIL PROTECTED] (see the proc.patch and suexec-shell.patch links in this message) * The 2.0.36 worker MPM graceless shutdown changes work
[patch] include/util_filter.h
add missing @param docs Index: include/util_filter.h === RCS file: /home/cvspublic/httpd-2.0/include/util_filter.h,v retrieving revision 1.74 diff -u -r1.74 util_filter.h --- include/util_filter.h 28 Jun 2002 08:40:23 - 1.74 +++ include/util_filter.h 2 Jan 2003 05:42:49 - @@ -328,6 +328,8 @@ * * @param name The name to attach to the filter function * @param filter_func The filter function to name + * @param filter_init The function to call before the filter handlers + *are invoked * @param ftype The type of filter function, either ::AP_FTYPE_CONTENT or :: *AP_FTYPE_CONNECTION * @see add_input_filter() @@ -344,6 +346,8 @@ * * @param name The name to attach to the filter function * @param filter_func The filter function to name + * @param filter_init The function to call before the filter handlers + *are invoked * @param ftype The type of filter function, either ::AP_FTYPE_CONTENT or * ::AP_FTYPE_CONNECTION * @see ap_add_output_filter() __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
