axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: thoughts re development towards 1.0
Date Sat, 02 Dec 2006 05:20:58 GMT
Samisa:

> I have figured out why it did not segfault for me.
> Now when I do the fix, it segfaults. Now I do understand the real need 
> for a separate global pool. I am trying to fix that next.

   Sorry, Samisa, I'd missed your previous comments -- my apologies!

>> Given that, I am wondering why there is a memory growth. Could you 
>> please help me understand this?

   It's probably because of the way APR memory pools work.  They
don't necessarily free() all the pool memory when you call
apr_pool_destroy() or apr_pool_clear().  That's left to the internal
allocator functions to decide; they may keep some of the memory
around for future use.  IIRC, allocator_free() in
memory/unix/apr_pools.c is the place to look.  If you want an
allocator that will free() everything immediately, you can
write such a thing and use apr_pool_create_ex(), but for use in
httpd, I think that's unwise -- just let APR do its normal memory
management for you.

>>> I hope when we do this, the memory growth would come under control.
>>> However, some effort is required to differentiate between 
>>> configuration data versus per request data. (Well, the description 
>>> hierarchy and some parts of the configuration hierarchy have long 
>>> life. However, these may be mixed up with per request stuff.)

   Yes, that's really the crux of it, I think.  I figured that if
per-request and configuration data are getting mixed up, some of those
cases might be rather subtle and hard to catch.  Still, I think this
would really be worth the effort, because it would simplify code
maintenance quite a bit down the road, and ensure that you don't
have to keep fighting memory leaks (or overly agressive freeing)
in one place or another.

>>> I am yet to try these suggestions. Anyway, it looks to me that we 
>>> have to get rid of the macros and ops indirection altogether.  And 
>>> yes, it will obviously take considerable time and effort. So lets try 
>>> these suggestions for 1.0 time frame.

   I was trying to think of a way to retain the ops indirection and
macros, mostly just to make the task manageable, but if there are
other reasons to remove them, then I suppose that might be for the best.
But, FWIW, my original suggestion was more of a workaround solution
with the goal of trying to minimize the scope of the changes (although
it would still be a lot of effort, adding checks to all the macros).

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message