apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: SMS as Pools Patch
Date Thu, 12 Jul 2001 10:35:28 GMT
> > 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


Mime
View raw message