celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: [DISCUSS] APR Usage
Date Thu, 26 Sep 2013 19:31:33 GMT
Hi All,

To be honest I see two discussion

1) Do we want APR with Native-OSGi ?
Here I can be short. No. APR is not a standard and not a de facto
standard, because it is not that heavily used, ss result it should not
be in a standard API spec.

2) Is APR - and more specifically APR pools - the right solution for a
OSGi approach in C.
Here is disagree. Personally I like apr pools and IMO it helps
organising big chunks of work and the memory needed for that. I agree
that it is oriented around the request and handle workflow, but there
is support for unmanaged pools and unmanaged pools could be used to
swap ownership. I also think that it is the responsibility of the
services that need to give away ownership of memory to arrange that in
the service API. APR pools can be used for, but is not needed and up
to the developer of the service.

I think ownership in C will always be difficult, we don't have a
garbage collection or reference counters and we have to think in
ownership. I more worried that for the Java OSGi API there isn't
always a good mapping.

For example the problem we ran into was the a bundle A looked up a
service reference and forwarded this to bundle B. But when bundle A is
removed the allocated memory for that service reference was removed
and bundle B had a bogus service reference. Hard bug to find, easy to
This was in the RemoteServiceAdmin and the Java API is
exportService(ServiceReference reference,
java.util.Map<java.lang.String,java.lang.Object> properties)
But I think i C we should not never forward a service reference, but
provide the serviceId.

But in conclusion if we want to support Native-OSGi I think we should
drop APR pools in API.


On Thu, Sep 26, 2013 at 1:09 PM, Alexander Broekhuis
<a.broekhuis@gmail.com> wrote:
> Hi All,
> Recently we (Pepijn and I) ran into a problem where the root cause was the
> usage of ARP (memory pools). Eventually the fix wasn't that difficult, but
> we discussed the use of APR, or more specifically, the use of memory pools.
> The problem has to do with the fact that once memory is allocated on a
> certain pool, it is not possible to change ownership of that memory. Taking
> into account the model we use, in which a bundle has two pools, one use by
> the framework, the other for use by the bundle's logic (the actual
> component/service), the following becomes a problem:
> If a bundle allocates a block of memory and then calls a service from
> another bundle with that memory (eg by passing a data member as argument),
> the ownership isn't transferred. So if the first bundle is stopped, the
> memory of the data member is also cleared, resulting in memory exception in
> the second bundle.
> Of course is it possible to create a copy of the data on the receiving end,
> but from a user/developer point of view that doesn't make any sense. When
> reasoning why this is an issue with the use of APR, I can come up with the
> following: APR has been developed for the HTTPD project, which is request
> based. So when a request is handled, an new pool is created, the request is
> handled and a reply is send, and then the pool can be removed. So basically
> the state model is quite different when comparing to Celix, bundles can
> come and go, and pools shouldn't interfere with this.
> Even though APR has manny benefits when looking at the platform
> abstractions (file handling/threading etc) it fully relies on memory pools.
> So my question is: Taking above statement into account, do we want to use
> APR, or do we want to move to our own memory model?
> If we move to our own model, there is also a benefit when looking at
> Native-OSGi. As reference implementation of Native-OSGi we need to change
> the API's to the specified versions. And Native-OSGi doesn't use and/or
> promote APR on the API. So the work we need to do to come up with a memory
> model can be used as input for Native-OSGi (also we can collaborate with
> the Native-OSGi guys on this). But it also means that we need to make our
> own platform abstraction (Celix compiles on windows and linux/unix at this
> moment, and I think this should stay possible).
> So what do others think?
> --
> Met vriendelijke groet,
> Alexander Broekhuis

View raw message