[PATCH] Re: cvs commit: httpd-2.0/modules/http mod_mime.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

From: <wr...@apache.org>
Sent: Thursday, August 16, 2001 3:04 PM


> wrowe       01/08/16 13:04:33
> 
>   Modified:    .        CHANGES
>                modules/http mod_mime.c
>   Log:
>     Push back CHANGES to document the complete mod_mime segfault solution.
>     Rounded out the mod_mime Add/Remove pairs by adding RemoveLanguage
>     and RemoveCharset directives, and rolled in the remove_items handling.
>     This is (effectively) my complete patch, sans pool optimizations.
>     [William Rowe]

Dang... had to update/reattempt to commit so many times I forgot to point out...
this patch also reorders the directive handlers into alpha order, for clarity.

This is pushed into 2.0.24 - G. Ames - would you give it a shot on Daledeus?

In a complete irrelevant tag-push (to anyone but Win32 users) I've pushed the
support/win32/ApacheMonitor stuff forward as well, since several bugs are fixed.

Now, this is a far as I can take it.  Segfaults (from the hash _and_ the elements)
should be gone.  I don't have the time or energy to focus on the optimization patch 
to reflect this last update, especially as exactly one (1) individual has commented
on the 'optimization guideslines' draft I posted.

If anyone doesn't like the performance heuristics, try backing out hashes and just
restore tables, _without_ breaking any of the (non-hash) bug fixes that were recently 
introduced.

Bill

Re: [PATCH] mod_mime pool testing against cvs head

[Brian Pane <bp...@pacbell.net>]

William A. Rowe, Jr. wrote:

>>Now, this is a far as I can take it.  Segfaults (from the hash _and_ the elements)
>>should be gone.  I don't have the time or energy to focus on the optimization patch 
>>to reflect this last update, especially as exactly one (1) individual has commented
>>on the 'optimization guideslines' draft I posted.
>>
>
>Ok... last chance.  Here's the optimized patch against the current tree.
>
>Anyone who suggests this adds wicked complexity is fooling themselves, it's no more
>nasty than actually assuring that your hash table or elements aren't being corrupted.
>
The patch looks good to me.  In the common case that ought to be fast
(no .htaccess files, and no remove lists), this new logic doesn't have
to dup the hash tables or their contents, so I'm comfortable with it
from a performance perspective.

--Brian

[PATCH] mod_mime pool testing against cvs head

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> Now, this is a far as I can take it.  Segfaults (from the hash _and_ the elements)
> should be gone.  I don't have the time or energy to focus on the optimization patch 
> to reflect this last update, especially as exactly one (1) individual has commented
> on the 'optimization guideslines' draft I posted.

Ok... last chance.  Here's the optimized patch against the current tree.

Anyone who suggests this adds wicked complexity is fooling themselves, it's no more
nasty than actually assuring that your hash table or elements aren't being corrupted.

I'm also cheating, using the apr_hash_pool_get() accessor rather than wasting a pool
pointer in the dir_config.

To Brian's well thought out question; yes, if you save three snapshots while building
a dir_config, let's say the /, /foo/ and /foo/bar/ points, you must actually create
three sub-pools (each a sub pool of the prior pool, most likely.)  Since you may likely
ditch /foo/bar/, or even /foo/, before / becomes stale (let's say you detected an
.htaccess change), this sub pool requirement certainly isn't unreasonable.  You can
then destroy the /foo/bar/ pool and reclaim the memory, while building a new subpool
of the /foo/ point, and pick up your walk again from /foo/ :)  

Feel free to benchmark and vote it up or down, on performance alone.  Bill was right,
the /www/www.apache.org/dist tree provides a very nice performance measure and
diagnostic example for complex sites :)

Bill

Re: [PATCH] Re: cvs commit: httpd-2.0/modules/http mod_mime.c

[Bill Stoddard <bi...@wstoddard.com>]

I am receiving cvs commit messages about two hours after the commit :-( TGFViewCVS

The patch that went in right before this patch looks reasonable. It is basically the same
as the patch I posted with some tweaks to not merge when there is nothing to merge. And it
gets rid of the god awful copy/copy_mappings gorp. I expect to +1 it unless I find a bug
in it. Thank you for coming around to my point of view :-)


> From: <wr...@apache.org>
> Sent: Thursday, August 16, 2001 3:04 PM
>
>
> > wrowe       01/08/16 13:04:33
> >
> >   Modified:    .        CHANGES
> >                modules/http mod_mime.c
> >   Log:
> >     Push back CHANGES to document the complete mod_mime segfault solution.
> >     Rounded out the mod_mime Add/Remove pairs by adding RemoveLanguage
> >     and RemoveCharset directives, and rolled in the remove_items handling.
> >     This is (effectively) my complete patch, sans pool optimizations.
> >     [William Rowe]
>

This patch OTOH.... You need to see a doctor about whatever compelled you to reorder the
functions alphabetically :-) This just create unnecessary clutter in the CVS history.  Not
unlike replacing tabs with spaces.

Bill