On 06/05/2012 08:43 PM, Alexander Broekhuis wrote:
Hi,
So bundles could use different pools for different API calls. Maybe that
kind of flexibility is enough... If there is no bundle specific "mem_alloc"
function, the framework could fall back to usual malloc/free calls. Does
that make sense?
This still ties the user to a fixed lifetime for pools, still leaving the
possibility for unneeded memory growth. The user should be in absolute
control of the memory and when it has to be cleared. So for each call
(similar or not) it can decide how to handle the memory. Tying it to a
function still is a rather fixed solution.
Hm, I think you misunderstood me, or I did not fully understand the
problem. We are talking about memory which is actively allocated by the
framework (by calls to free or some hook provided by a bundle) but which
is owned by the API user, right?
My suggestion was (if we really want that kind of complexity) that the
bundle writer (user of the API) can use the function pointer passed to
the memory hook by the framework to decide on which internal pool the
memory should be allocated. So the user has full control over the
lifetime (e.g. via memory pools).
I'm with Pepijn on this one, user the regular "malloc" and let the user
"free" it is the best for now I think.
That is definitely the most "common sense" solutions and is what I also
suggested at the very beginning.
Best,
Sascha
