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 Fri, 01 Jun 2012 13:35:38 GMT
On 05/30/2012 01:12 PM, Pepijn Noltes wrote:
> On Wed, May 30, 2012 at 11:53 AM, Alexander Broekhuis
> <a.broekhuis@gmail.com>  wrote:
>> Hi all,
>> I'm looking to extract the current Celix API to the Native-OSGi project,
>> and running into some issues related to data/memory ownership.
>> Celix uses APR and memory pools for memory management. In cases where the
>> API returns some data, the user supplies a pool, and the framework
>> allocates the needed memory on that pool. This makes the user the owner of
>> the data.
>> At the moment Celix doesn't solve this nicely, sometimes data is allocated
>> on the supplied pool, sometimes a pointer is returned.. But this is another
>> issue.
>> Some examples of this can be found in bundle.h, eg bundle_getEntry.
>> In the Native-OSGi specification we don't want to use APR (or impose it on
>> others), so basically the question is, how do we want to handle functions
>> where some data is returned?
>> Some possible solutions:
>> - Keep it on the call stack, so it gets out of scope.
>> - Ignore APR, and allocate the memory, making the user responsible for
>> freeing it.
>> Are there any other options I am missing? And is there a common solution
>> for problems like this?
> Another option is to let the user provide a buffer and its size. Then
> the user can choose to use a pool,the stack or malloc/free. The
> downsize is that you do not known how big the buffer has to be and
> therefore there is change that the buffer is to small and additional
> action / return parameter is required.
> Greetings,
> Pepijn


I'm not a C - expert, but I think the only viable solution is to 
accurately document the lifetime and ownership of pointers.

For memory owned by the framework, any memory management technique which 
guarantees the stated lifetime will do (e.g. APR memory pools).

Memory which is to be owned by the caller (user) could probably be 
allocated and deleted by using special functions (hooks) provided by 
each bundle which use implementation specific routines for memory 
management. Otherwise we just state that the returned memory belongs to 
the caller.


View raw message