Re: callback functionality for dyanmic memory allocation

[NavEcos <ecos at navosha dot com>]

On Tuesday 05 November 2002 01:50 am, Jonathan Larmour wrote:
> NavEcos wrote:
> >>Also, how about writing a test or two?  These are the best examples
> >>we can provide the public of anything that gets added.
> >>
> >>Thanks.  (I'll let Jonathan comment on the patch as a whole)
> >
> > I am using the addtional functionality already - but before I publish
> > examples, I think it would be best to see what eCosCentric thinks.  I
> > expect there will be some discussion about changes -> once the additional
> > API's are solidified I'll be happy to produce examples.
>
> Well, okay you asked for it ;-). I'm not convinced of the need to have the
> callback functions being a zillion different types, most of which are
> pretty similar (pool, ptr, size most times).
>
> I think it may make for a more understandable interface if it's a single
> type, with an "operator" enum indicating what function is being performed.
> I would even go as far as suggesting, since the primary use of this is
> debugging, that there even only be one function that's called full stop.
> i.e. instead of 8 statics, there's just the one. If the user's callback
> isn't interested in a particular operation, it can just drop out and
> ignore it.
>
> This callback could be of type (e.g. for dlmalloc):
>
> typedef void Cyg_mempool_dl_callback_fn( enum Cyg_Mempool_dl_op op,
> Cyg_Mempool_dlmalloc *pool, const cyg_uint8 *base_ptr, cyg_int32 size,
> cyg_int32 *newsize );

OK - no big deal although you'll need parameters for the allocated
pointer and also an "original size" for realloc.  That should cover
it I think.

> Obviously, unused arguments for the particular op can just be ignored.
>
> I think this would greatly simplify this for users. Having so many
> different callbacks and types seems cumbersome.
>
> I'm not clear on why for e.g. fn_pre_realloc_cb you want to take the
> _address_ of alloc_ptr. alloc_ptr itself should do. Ditto for other
> cyg_uint8**.

To modify the pointer.  Say you want to put a guard band at the
beginning of the allocated block of memory for example.

> You've left in a test_fun in dlmalloc.

did I?  I'll be more careful in the future.  :P

> This is definitely large enough for a copyright assignment, so that's
> required before it can be included.

No problem.  I'll get that into the mail tomorrow.  I have authority
to sign documents for my company.

> Just when it comes to code layout, I think it's superior that instead of
> e.g.
>
> #ifdef CYGSEM_MEMALLOC_ALLOCATOR_FIXED_CALLBACK
>      cyg_uint8
>        *pRet;
>
>      if ( fn_pre_alloc_cb != NULL ) {
>         (*fn_pre_alloc_cb) (this);
>      }
>
>      pRet = mypool.try_alloc( 0 );
>
>      if ( fn_post_alloc_cb != NULL ) {
>         (*fn_post_alloc_cb) (this, &pRet);
>      }
>      return pRet;
> #else
>       return mypool.try_alloc( 0 );
> #endif
>
> we have:
>
>      cyg_uint8 *pRet;
>
> #ifdef CYGSEM_MEMALLOC_ALLOCATOR_FIXED_CALLBACK
>      if ( fn_pre_alloc_cb != NULL ) {
>         (*fn_pre_alloc_cb) (this);
>      }
> #endif
>
>      pRet = mypool.try_alloc( 0 );
>
> #ifdef CYGSEM_MEMALLOC_ALLOCATOR_FIXED_CALLBACK
>      if ( fn_post_alloc_cb != NULL ) {
>         (*fn_post_alloc_cb) (this, &pRet);
>      }
> #endif
>      return pRet;
>
> It makes more sense to me.

Either one.  I thought it was less noisy the first way, but I'm not
religous about it.

> Feel free to add yourself as a contributor at the top BTW. It's up to you.

OK :)

> > Also, to help understand it: the dlmalloc and variable heaps have nearly
> > identical APIs but the fixed alloc is a bit different.
> >
> > If you have any questions, feel free to ask.
>
> Done :-). To echo Gary, a test would be good. Or failing that, just a
> little guide on how to use it which can go in the package's doc directory.
> ASCII text would be good enough since there isn't already an SGML doc to
> hook into (but if you wanted to start one that would naturally be fine too

I promise to produce examples and full documentation.  Let me submit
another diff file, let you guys look at it and comment on it, and
then I'll give complete examples.

> :-)).
>
> Jifl

Thanks,
-Rich