Luke Kenneth Casson Leighton wrote:
On Wed, Jul 11, 2001 at 06:48:29PM +0200, Sander Striker wrote:
Ah, ok. The implementation of an sms calls apr_sms_child_malloc
instead of apr_sms_malloc when it wants memory from its parent.
.... okay... why?
Because there are situations where we would like to treat allocations
from a child sms different than from a user.
okay... such as?
... and is this a slippery slope?
first, we have user allocations. then we have child sms allocations.
then there is ... grandchild sms allocations? then, maybe,
faster sms allocations? then, maybe... sms allocations that
are going to be a massive-repeat-loop on realloc, later [sander knows
why this is: i'll explain it briefly, here. DCE/RPC function call
transfers are split up into Protocol Data Unit sizes of a typically
negotiated size of 0x1630 - 5680 - bytes. there is no limit on
the *actual* amount of data that is transferred, and i'm not
joking about that. NT has a hard-limit of 5megabytes but in
practice, services tend to terminate with prejudice if you go
above 1mb. you therefore receive potentially hundreds of 0x1630
byte data blocks, and you have to strip out the first 16 bytes
and chain the rest together...]
in other words, would it be better to have an extra parameter to
the malloc to indicate what the sms should do? advice to the
sms as to the _type_ of alllocation being performed?
Here's a possible taxonomy of allocation types:
Type 1: Allocations that will not be returned to the SMS (and will
get freed only when the SMS itself is destroyed)
Type 2: Allocations that will be returned to the SMS during its
lifetime
The first type includes most appliation data structures
allocated from per-request pools in the httpd: small strings
and structs. For these, the optimal implementation uses O(1)
pointer arithmetic for allocation (like apr_sms_trivial or
the original pool code), and deallocation is a no-op.
The second category includes bigger allocations: the messages
in your RPC example, and subrequests in the httpd. For these,
the deallocation can't be a no-op. Instead, the space being
returned to the SMS should actually be made available for
subsequent allocation requests. And the allocation/deallocation
logic needs to be fast yet avoid too much fragmentation. To
perform well in the general case, it basically needs to be a
well-tuned malloc implementation.
Using this model, an SMS itself could figure out the type of
each allocation request based on the number of bytes requested:
small requests would get allocated out of the pool as in
apr_sms_trivial, and large requests would get delegated to
a root SMS that called malloc. (I guess an SMS that did this
would be a hybrid tracking/trivial SMS?)
--Brian
