httpd-dev mailing list archives

>I'm still wondering if we shouldn't just stick with the local
read/write
>lock on Windows and other single child MPMs (NetWare?) as this should
>allow better throughput in such cases and yet be safe, right? In
fact,
Actually on NetWare this is a non-issue. On NetWare everything is
global (memory, locks, etc.), so there is no difference between a global
mutex and a local one (other than previously we were using reader/writer
locks rather than mutexes). I would like to use reader/writer locks
rather than global mutexes simply for performance reasons, but I'm not
sure how we would go about switching between global and local locks
anyway. This would require #ifdef'ing the code for particular platforms
or MPM's which isn't a good thing.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> jessh@ptc.com Sunday, September 19, 2004 3:43:20 PM >>>
Sorry for the chattiness of my solution process. I've tested and these
fixes do apply with the global mutex changes *except* when one disables
caches by sizing them all to 0, Apache will crash on the first
authentication request when the global mutexes are used! This needs to
be fixed!
I've attached a unified diff containing the purge fix and the
unassigned
variable fix (which as Graham pointed out is already in the 2.1
branch).
I'm still wondering if we shouldn't just stick with the local
read/write
lock on Windows and other single child MPMs (NetWare?) as this should
allow better throughput in such cases and yet be safe, right? In fact,
why do we use shared memory on these platforms for the cache? [If I'm
just daft here, I apologize.]
--
Jess Holle
Jess Holle wrote:
> Here's a fixed LDAP purge routine which works great in my testing
> (with cache sizes of 8, 100, 1000, and 2150 and 2500 unique user
> logins repeated 3 times each). [No, I haven't produced a diff as I
> have pieces of util_ldap from various CVS levels at this point.]
>
> Essentially I added all the logic surrounding 'pp', which is the
> address of the previous node's 'next' field or of cache->nodes[i] in
> the case of the first node. [Cleary my C is getting rusty -- this
> took me a few attempts to get right...]
>
> This fixes the biggest LDAP module issue I'm aware of: hangs and
> crashes after one or more cache purges.