>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 >>> [EMAIL PROTECTED] 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.
