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
