> > Realistically, though my thought for the long term is to have one root > > trivial SMS (or similar SMS with a freelist) per thread > > and a bunch of > > tracking SMS (brain-dumb five-minute SMS that don't do much). I really > > think this is where we ought to be headed. Does that need the > > child_malloc path? Probably not. > > well... > > *thinks*. > > even _with_ the existing pools system, i've been watching the > messages go back-and-forth about how pools and threads are messing > everything up [general summary, i don't have the experience of > actually _using_ this stuff :)]. > > so, if that's the case, then there are two problems. > > one: pools in threads are messed up. > > two: sms can't be developed effectively because no changes are > allowed to existing code. and some of the solutions being proposed > involve pools and threads.
Well, the thread code is in apr so this can be easily touched without changing the httpd codebase. This way we isolate the changes to just be in apr (for now, optimization will require changes, but we need a stable, proven, sms codebase first). For ideas on resolving the problems take a look in the archive ;) Basically I wanted to do locking on demand (so when 2 or more threads are using a sms it locks, when only 1 thread uses it, it doesn't (default)). Maybe we need to change one(1) line in the threaded mpm in httpd to allow it to work as intended, ~1 free list per thread. Sander
