incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject [DISCUSS] APR Usage
Date Thu, 26 Sep 2013 11:09:08 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message