DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22233>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22233

MaxMemFree is ignored by winnt MPM





------- Additional Comments From [EMAIL PROTECTED]  2003-08-08 00:46 -------
http://httpd.apache.org/docs-2.0/mod/mpm_common.html#maxmemfree 
 
The MaxMemFree directive is supplied by mpm_common.  It sets the value of a 
global 
variable, ap_max_mem_free, which is supposed to be read by the mpm and passed 
to a call like: 
 
apr_allocator_max_free_set(allocator, ap_max_mem_free); 
 
where allocator is an allocator that you just created with 
apr_allocator_create() and 
subsequently pass to apr_pool_create_ex().  The problem is that the winnt mpm 
doesn't use apr_allocator_create() or apr_pool_create_ex() at all; it just uses 
apr_pool_create(), which takes the allocator from the pool's parent.  That 
allocator 
has no maximum set on it. 
 
What needs to happen is that you need one allocator (no mutex) per transaction 
pool.  
But what with the various recycling that gets done in that mpm, i was unclear 
what all 
needed to be modified to store the allocator and pass it around with its 
associated 
transaction pool. 
 
Once that's done, then we can create our bucket allocator with the upcoming 
apr_bucket_alloc_create_ex(), which will take an allocator (that same one) 
rather than 
a pool.  This makes everything Just Work(tm).  :) 
 
--Cliff 
 
 wrowe-travels adds even a trivial comment 
toapr_allocator_max_free_set(allocator, 
ap_max_mem_free); 
 all such bugs to keep them on  
his 'interesting' query 
<wrowe-travels> I would like to get 2.1 SSL -> 2.0 ssl before .48 - it's a 
project for  
the weekend. 
<jwoolley> the value set by this directive is completely ignored by the winnt 
mpm 
<jwoolley> no PR# 
<jwoolley> it's been an outstanding issue for like a year now 
<wrowe-travels> Sander Temme and I have been spending the week running  
SSL2.1 (within httpd-2.0) regressions and such 
<wrowe-travels> Hm... no pr, open issue  ..  Would seem to follow :) 
<jwoolley> ;) 
<wrowe-travels> Adding now 
<jwoolley> i didn't actually realize until circa .47 that it wasn't honored by  
mpm/winnt.  but i've known that support for it wrt bucket brigades' allocators 
was  
missing from all mpms since about a year ago.  i got a little sidetracked you 
could  
say ;) 
<jwoolley> up until now it's only controlled the size of the freelists used by 
pools'  
allocators, but that's not the way it ought to be. 
<jwoolley> so i fixed it.  in the mpm's that have support for it in the first 
place.  :) 
<wrowe-travels> :-) 
<jwoolley> there's a global var called (i think) ap_max_mem_free that you just  
have to pass to the appropriate apr_allocator_create_ex() call at the 
appropriate  
time. 
<wrowe-travels> Well I'd be happy to help hack with this. 
<wrowe-travels> Can you write up one para onto 22233? 
<wrowe-travels> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22233 
<jwoolley> the problem is that i'm unclear about how the lifetimes work with 
all of  
the completion contexts and recycling and such. 
<wrowe-travels> that gives me a hint on the variables and cite a line of code 
in  
worker or prefork mpm? 
<wrowe-travels> I don't mind dealing with those issues

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to