On Thu, 2009-07-16 at 01:19 +1200, Amos Jeffries wrote:
> A Henrik said, > people with large memory-hog helpers have issues when Squid allocates > more than N bunches of their carefully tuned available memory to its > helpers. This is also important in low-memory systems requiring auth. > > It's a simple 'start N' call now checks the number of running helpers > before blindly starting new ones. Making Squid actually follow its > numerous children=N settings. > > > I'm fine with reverting it in 3.1. But this is a nasty mix of sync and > async operations that does need cleaning up in 3.2. It's semi-hiding > about 4 bugs in a helpers and auth. I'm not sure it was hiding bugs - as Henrik also said, we sync *initiate* async shutdown of helpers, and startup new helpers. Similarly ACL processing of in-flight requests used to be refcounted, so the old config applies to existing requests, and new requests get new policies applied to them (because of the pointer into the acl chain that requests hold). Existing requests that move to new ACL chains get the new config, and it all works. As far as memory goes, I think we should document that when you reconfigure squid, *all* settings are duplicated until the transition is complete, so if you ask for 100 helpers, up to 200 will be held open per configuration-that-is-active. -Rob
signature.asc
Description: This is a digitally signed message part
