[Ur] missunderstanding - or serious memory handling issue?

[Marc Weber]

Excerpts from Adam Chlipala's message of Wed Dec 08 02:42:45 +0100 2010:
> Yes, no callback should touch any uw_malloc()ed memory.
So what is uw_malloc worth then? 

Let's compare this use case:

one struct has to be allocated keeping some ruby stuff.

current implementation:
  malloc must be used because I want to access it in a free handler
  I must ensure that the free handler reading from the memory is called
  before the handler which is freeing the malloced memory (Is this
  documented? Don't think so. So I have to assume that the order of
  calling free handlers in the uw_push_cleanup or
  uw_register_transactional never changes) - Should I even write a test
  case (?)

  - always 2 callbacks
  - always 1 alloc()
  - you have to think about more cases
  + uw_malloc can increase memory

alternative implementation which has a minimal heap and allocates
additional memory blocks when needed:
  - if the heap still could be increased continuously you don't know.
    You're wasting some memory
  + you can shrink heap again
  + you need one handler less
  + there is a chance that you don't have to call malloc at all
  + you don't have to care about freeing the memomry yourself

  The minimal heap is to prevent allocations for short pages.
  The additional blocks can be freed - so if no http request is being
  made mininmal memory consumption will be used - I'm not sure whether
  the OS can reclaim memory then - probably not.

So somehow this looks like being the better alternative to me. But I'm
puzzled. There is no realloc_try fnuction or such.
 
Probably I should define a macro which does all the work for me:

#define MY_URWEB_MALLOC(name, type, size) \
  type * name = malloc(size);             \
  // might cause trouble if surrounding code is calling uw_pop_cleanup \
  // uw_push_cleanup(name, free);         \
  uw_register_transactional(..... name, free);


and use that for my struct and stop worrying?
Going to bed now. cu

Marc Weber