Hello Nick, Thanks for your answer, we have been looking at APR some more, and came up with the following:
APR provides a good abstraction for common OSes so we want to use it. But to be able to use Celix on embedded/realtime platforms the idea is to use a dedicated "wrapper" in Celix. This wrapper, by default, will use APR making Celix usable on all APR supported platforms. Since this wrapper will only have a subset of the APR functions, it is easier to implement support for other platforms (not based on APR). For example, for memory allocation TLSF could be used (probably not as part of Celix, since it is licensed using GPL/LGPL). With regards to memory pools, there are basically four different lifecycle types, comparable to the pool types you describe in the linked article. * The framework pool, for the lifetime of the entire process * The bundle pool, for the lifetime of one bundle installed in the framework * The bundle runtime pool, for the lifetime of one bundle running in the framework (in OSGi, and therefor also Celix, an bundle can be started/stopped during its lifetime) * User request pools, for interaction a "user" has with the framework. This interaction is always through the bundle context, so it is possible to wrap/hide some usage in the bundlecontext. Does this make sense? -- Met vriendelijke groet, Alexander Broekhuis
