axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: thoughts re development towards 1.0
Date Sat, 02 Dec 2006 14:27:34 GMT
Chris Darroch wrote:
>    Sorry, Samisa, I'd missed your previous comments -- my apologies!
No problem. Glad to hear from you.
> 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 took your advice and let APR do the normal memory management. And yous 
you are right, though there is a growth, it drops after some time and 
again starts to grow (I ran echo sample 200000 times)
>>>> 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 gave it a try and it seems to work. What I did was is to place the 
whole of description hierarchy and part of the context hierarchy, 
starting from operation context and upwards (that is op_ctx, svc_ctx, 
svc_grp_ctx and conf_ctx) in to global pool. The rest is in the request 
pool and the trick seems to work. Not the ideal solution but we can use 
this as our starting point I hope.

What I would do is that, I would test this a bit more, ensure that it 
does not crash in an ad-hoc manner and then commit the stuff.
Once committed, if you could give it a try again and let us know the 
status, that would be great. In the latest fix, in addition to your 
patch, I have also introduced a global pool to the allocator as you had 
suggested earlier. I would let you know, once I commit the stuff.
>>>> 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).
Lets start with macros improvements that you have suggested, then we can 
see what else to do.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message