Flood developers, APR gurus, Cliff Wooley, Sander Striker, etc.: Looks like I'm in the process of implementing the needed fix of implementing multiple pool levels in Flood. The decision point is going to be between allocating a new pool from the source pool every repeated instance (i.e. each time a url-testing is attempted by a virtual user) which is then destroyed before the next url is encountered, or creating the subpool for requests/responses once from its parent and clearing the pool after each url finishes. I want to know (1) if any memory is actually released when the pool is cleared and (2) what you see as performance hits for each method. I notice that Flood, on a "session" level (virtual user or "farmer" executing one round of a list of urls in a profile), performs the second option, clearing the subpool after each session. Also, if memory is not actually released in that event, is the cleared subpool at least going to properly reuse the memory it has already allocated? Once the farmer_pool has been cleared, I assume that at that time any subpools it had would need to be recreated (by an apr_pool_create()).
-Norman Tuttle [EMAIL PROTECTED] Developer, OpenDemand Systems PS: After a call to apr_socket_connect(), is the allocated quantity pointed-to by its 2nd (apr_sockaddr_t *) argument required to stay around for the duration of the life of the socket, or is its value used immediately and it can be deallocated? I will check myself but perhaps someone knows offhand. On Thu, 13 Nov 2003, Sander Striker wrote: > On Thu, 2003-11-13 at 16:26, Cliff Woolley wrote: > > On Thu, 13 Nov 2003, Norman Tuttle wrote: > > > > > How do the pools define "if possible" in your wording below (i.e., how > > > would the pool know when to reuse memory)? > > > > It's kind of complicated, so I don't know how well I can explain it off > > the top of my head (Sander, feel free to jump in here :), but it keeps > > freelist buckets of varying power-of-two sizes, and if it finds one of the > > appropriate size, it will use it. > > The allocator keeps freelists of multiples of 4k blocks actually ;) > > > But there are two levels of things going on, too, because the allocator > > hands out blocks of a certain size, which the pools then divide up into > > smaller blocks... > > Pools get blocks from the allocator. Pools then hand out the requested > memory to the caller. They hold on to the 'surplus' for the next > allocation. > > On a pool clear, all used blocks return to the allocator (except for > the block containing the pool itself (8k)). > > > Oy. > > > > Sander? Help me out. :) > > You know what, this question comes up reasonably frequently. Enough for > me to start writing a document on this. > > I'll post a URL later on. > > > Sander >
