apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: [PATCH] Allow unrelated SMSes to reset
Date Thu, 19 Jul 2001 08:57:24 GMT
> On Wed, Jul 18, 2001 at 11:02:27AM -0500, William A. Rowe, Jr. wrote:
> > > And enforcing that the 'allocation' pool is either top-level itself,
or a
> > > descendant of the 'scope' pool, assures that the cleanups will unwind
> > > properly for both (since this thread-child pool is torn down,
everything below
> > > in the 'scope' heirarchy will be cleaned up, as well).
> >
> > Err... "enforce that the 'allocation' pool is either top-level itself,
or the
> > same as or one of the parents of the 'scope' pool".
> Yes.
> The trick, as I see it, is that we let the apr_thread_create function
> determine what the apr_thread_t's SMS is.  If the thread_create
> function says the allocation SMS is now a "top-level" one or whether
> it uses the pool passed in.
> BTW, I'm not sure that the apr_pool_cleanup_for_exec will do the right
> thing in the SMS architecture because there is no common parent anymore.
> We may need to rethink how that function works.  Thoughts?
> Of course, everyone realizes that in order to do all of this, we have
> to get SMS working.  -- justin

Well, a few quick comments...

- sms does seem to work, so your comment seems a little strange though very
Justin :)
- how in hells name have we taken a nice simple set of concepts and made
such a pigs ear of them?  I mean we started with 1+1=2 and we seem to be at
quantum physics level at the moment.  Maybe we should all agree to stop and
take an evening off before we get too far u our own...  Well, you get the

What problem are we trying to fix here?  That's the one that never seems to
be answered...  ISTR that we are basically saying that memory allocated
within a thread doesn't have to be locked as it's only available within a
single thread.  Well, we have a lot of ways of doing that already...

All memory is heirachical or we have real problems, especially in httpd.
1. If we have a "memory thingymebobby" go away then it needs to remove
itself and all those who are based in it - can we all garee this?
2. the pools code isn't truly heirachial as all memory comes from the same
source, so while you have relationships they exist at a management level not
at a resource level.  sms the relationships exist at both levels.
3. we don't like globals (with good reasons) but pools currently use a
global that leads to many locking issues.

It seems to me that there are so many ways of doing this that we're already
talking about adding more and more complexity when we may not need to.

For instance, have the apr_initialize function create an sms that will
handle all top level allocations, and get every sms we create to call it for
getting memory.  This mimics what we do at present with pools, and allows us
to do cleanups and so on exactly as per pools, but it does add another evil


View raw message