celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Zelzer <s.zel...@dkfz-heidelberg.de>
Subject Re: [Native-OSGi] OSGi API: Allocated memory ownership
Date Tue, 05 Jun 2012 19:40:56 GMT
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.


View raw message