On 05/30/2012 01:12 PM, Pepijn Noltes wrote:
On Wed, May 30, 2012 at 11:53 AM, Alexander Broekhuis
<[email protected]> 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
Hi,
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.
Best,
Sascha
