apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: SMS as Pools Patch
Date Thu, 12 Jul 2001 09:50:17 GMT
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

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?)


View raw message