>The current code is using some 'interesting' tricks with the jk_pools -
>it does some funny buffer allocations on the stack and use the buffer
>to create a pool ( which itself is allocated on the stack ).
>
>While this may have some performance benefits, the code is
>extremely hard
>to read, and doesn't 'map' to the new APR pool.
>
>What I would like to do ( if nobody objects ) is to use:
> struct jk_pool {
>
> ...
> jk_pool_t *(*createChild)( jk_pool_t *_this, int sizeHint );
> ...
> }
>
>The pool_open, etc will be removed - same for the buf[] based
>allocation.
why not. Frankly you love too much java :)
>Given that we recycle the endpoint ( and it's pool ) - I don't
>think we'll
>loose too much. If APR is used we'll use apr pools anyway ( which don't
>have support for the funny stack allocation ). For non-APR case, malloc
>will be fine.
>
>I'll also go ahead and replace all mallocs in the code to use the
>pools.
>
>However, I'm not an C expert ( or even a C programmer ) - if
>I'm missing
>something please let me know.
free must match malloc, that's all for now :=)
Question could be about recycling pools.
PS: Costin, you go too fast, I didn't recognize anything in jk2 ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
