You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@celix.apache.org by Alexander Broekhuis <a....@gmail.com> on 2011/04/15 10:01:08 UTC
Usage of Apache Portable Runtime in Celix
Hi all,
Some while ago I started looking at the usage of APR in Celix.
APR provides an abstraction to OS specific tasks (file io, threading
etc), the use of APR possible makes it a lot easier to port Celix to
different platforms.
Also, APR uses memory pools for allocation and deallocation, this
could make memory management easier.
Memory pools can, for example, be used for:
- each bundle (create during installation, destroy during
uninstallation/shutdown)
- each started component (create during activator create, destroy
during activator stop)
etc.
To be able to make this work, it is important to define the lifecycle
of "objects" in the framework. This makes it possible to keep the
dynamics, but loose all freeing and destroying of allocations
throughout the code.
Of course there are also some issues, mostly concerning with the
target platforms of Celix. One of the goals is to be able to use Celix
in embedded environments. APR currently does provide support for most
uses OSed (linux, windows, bsd, ...) but not for embedded platforms
such as TI's SYS/BIOS (previously named DSP/BIOS).
Maybe (part of) the APR headers can be used to implement it for other platforms.
I would like to know if this is something we can use in Celix, and
maybe if there is someone with more knowledge about APR who can help
look at how APR can be integrated and used.
--
With kind regards,
Alexander Broekhuis
Re: Usage of Apache Portable Runtime in Celix
Posted by Alexander Broekhuis <a....@gmail.com>.
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
Re: Usage of Apache Portable Runtime in Celix
Posted by Alexander Broekhuis <a....@gmail.com>.
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
Re: Usage of Apache Portable Runtime in Celix
Posted by Nick Kew <ni...@apache.org>.
On Tue, 26 Apr 2011 16:34:55 +0200
Alexander Broekhuis <a....@gmail.com> wrote:
> Some questions I have:
> One of the possible targets of Celix is the embeded world. Is there
> some work and/or knowledge regarding the usage of APR with for example
> TI SYS/BIOS? If not, it is possible/difficult to implement (a subset
> of) the APR headers for other platform?
I don't think APR cares much. You would have to instantiate
those APR APIs that aren't currently available for the platform.
I wouldn't go down the road of a subset of the APR headers. I once
did that, and it was a mistake. However, you can achieve the same
result by returning APR_ENOTIMPL error for functions you have yet
to support. That is common practice, and APR applications should
expect to handle the error.
> What is a good way to look at the usage of memory pools? Celix
Pools aren't just about memory. You can allocate any kind of
resource and tie it to a pool to ensure timely cleanup.
The crucial question is how you define timely cleanup. If you
have objects with well-defined lifetimes that can be cleaned up
without undue complexity, then pools are a good match. If not
then pools may create more problems than they solve. Pools are
central to APR, so the question of whether pools work well for
you is likely to determine whether APR itself is worth your while.
> provides a middleware layer on top of which functionality must be
> deployed. Should the use of APR be something we enforce to the users?
> Or can we keep the APR usage internal, so the user can still decide
> what to do.
If you use APR internally then you should encourage your applications
to do likewise.
> So now I'm struggling with when to use a new pool, when to clean the
> pools etc. Is there some general advice for this, or does it depend to
> much on the design of Celix?
If those questions cause you problems, it could be an indication
that pools are not a good match for your proposed usage.
Take a look at httpd usage, where pools are a great match for objects
like a TCP connection or HTTP request having a well-defined lifetime,
and work nicely to manage everything you allocate in processing a request.
And read my ancient piece at http://www.apachetutor.org/dev/pools
--
Nick Kew
Available for work, contract or permanent.
http://www.webthing.com/~nick/cv.html
Re: Usage of Apache Portable Runtime in Celix
Posted by Nick Kew <ni...@apache.org>.
On Tue, 26 Apr 2011 16:34:55 +0200
Alexander Broekhuis <a....@gmail.com> wrote:
> Some questions I have:
> One of the possible targets of Celix is the embeded world. Is there
> some work and/or knowledge regarding the usage of APR with for example
> TI SYS/BIOS? If not, it is possible/difficult to implement (a subset
> of) the APR headers for other platform?
I don't think APR cares much. You would have to instantiate
those APR APIs that aren't currently available for the platform.
I wouldn't go down the road of a subset of the APR headers. I once
did that, and it was a mistake. However, you can achieve the same
result by returning APR_ENOTIMPL error for functions you have yet
to support. That is common practice, and APR applications should
expect to handle the error.
> What is a good way to look at the usage of memory pools? Celix
Pools aren't just about memory. You can allocate any kind of
resource and tie it to a pool to ensure timely cleanup.
The crucial question is how you define timely cleanup. If you
have objects with well-defined lifetimes that can be cleaned up
without undue complexity, then pools are a good match. If not
then pools may create more problems than they solve. Pools are
central to APR, so the question of whether pools work well for
you is likely to determine whether APR itself is worth your while.
> provides a middleware layer on top of which functionality must be
> deployed. Should the use of APR be something we enforce to the users?
> Or can we keep the APR usage internal, so the user can still decide
> what to do.
If you use APR internally then you should encourage your applications
to do likewise.
> So now I'm struggling with when to use a new pool, when to clean the
> pools etc. Is there some general advice for this, or does it depend to
> much on the design of Celix?
If those questions cause you problems, it could be an indication
that pools are not a good match for your proposed usage.
Take a look at httpd usage, where pools are a great match for objects
like a TCP connection or HTTP request having a well-defined lifetime,
and work nicely to manage everything you allocate in processing a request.
And read my ancient piece at http://www.apachetutor.org/dev/pools
--
Nick Kew
Available for work, contract or permanent.
http://www.webthing.com/~nick/cv.html
Fwd: Usage of Apache Portable Runtime in Celix
Posted by Alexander Broekhuis <a....@gmail.com>.
Hello APR and Celix community,
Some while ago I posted the message below the the Celix developers
list, and I think it might be useful to ask the same questions on the
APR list.
To summarize, Apache Celix is an incubator project aiming at the
implementation of the OSGi specification in C
(http://incubator.apache.org/celix/). And lately I've begun looking at
APR as a possible platform abstraction.
Some questions I have:
One of the possible targets of Celix is the embeded world. Is there
some work and/or knowledge regarding the usage of APR with for example
TI SYS/BIOS? If not, it is possible/difficult to implement (a subset
of) the APR headers for other platform?
What is a good way to look at the usage of memory pools? Celix
provides a middleware layer on top of which functionality must be
deployed. Should the use of APR be something we enforce to the users?
Or can we keep the APR usage internal, so the user can still decide
what to do.
Celix exists out of a framework. On top of this framework bundles can
be installed. Inside a bundle is the user written software.
Interaction with the framework is always via the context of the
bundle. So from this point of view we could "hide" the apr usage from
the user, but still provide hooks if a user wants to use it.
So now I'm struggling with when to use a new pool, when to clean the
pools etc. Is there some general advice for this, or does it depend to
much on the design of Celix?
Thanx in advance,
---------- Forwarded message ----------
From: Alexander Broekhuis <a....@gmail.com>
Date: 15 April 2011 10:01
Subject: Usage of Apache Portable Runtime in Celix
To: celix-dev@incubator.apache.org
Hi all,
Some while ago I started looking at the usage of APR in Celix.
APR provides an abstraction to OS specific tasks (file io, threading
etc), the use of APR possible makes it a lot easier to port Celix to
different platforms.
Also, APR uses memory pools for allocation and deallocation, this
could make memory management easier.
Memory pools can, for example, be used for:
- each bundle (create during installation, destroy during
uninstallation/shutdown)
- each started component (create during activator create, destroy
during activator stop)
etc.
To be able to make this work, it is important to define the lifecycle
of "objects" in the framework. This makes it possible to keep the
dynamics, but loose all freeing and destroying of allocations
throughout the code.
Of course there are also some issues, mostly concerning with the
target platforms of Celix. One of the goals is to be able to use Celix
in embedded environments. APR currently does provide support for most
uses OSed (linux, windows, bsd, ...) but not for embedded platforms
such as TI's SYS/BIOS (previously named DSP/BIOS).
Maybe (part of) the APR headers can be used to implement it for other platforms.
I would like to know if this is something we can use in Celix, and
maybe if there is someone with more knowledge about APR who can help
look at how APR can be integrated and used.
--
With kind regards,
Alexander Broekhuis
--
Met vriendelijke groet,
Alexander Broekhuis
Fwd: Usage of Apache Portable Runtime in Celix
Posted by Alexander Broekhuis <a....@gmail.com>.
Hello APR and Celix community,
Some while ago I posted the message below the the Celix developers
list, and I think it might be useful to ask the same questions on the
APR list.
To summarize, Apache Celix is an incubator project aiming at the
implementation of the OSGi specification in C
(http://incubator.apache.org/celix/). And lately I've begun looking at
APR as a possible platform abstraction.
Some questions I have:
One of the possible targets of Celix is the embeded world. Is there
some work and/or knowledge regarding the usage of APR with for example
TI SYS/BIOS? If not, it is possible/difficult to implement (a subset
of) the APR headers for other platform?
What is a good way to look at the usage of memory pools? Celix
provides a middleware layer on top of which functionality must be
deployed. Should the use of APR be something we enforce to the users?
Or can we keep the APR usage internal, so the user can still decide
what to do.
Celix exists out of a framework. On top of this framework bundles can
be installed. Inside a bundle is the user written software.
Interaction with the framework is always via the context of the
bundle. So from this point of view we could "hide" the apr usage from
the user, but still provide hooks if a user wants to use it.
So now I'm struggling with when to use a new pool, when to clean the
pools etc. Is there some general advice for this, or does it depend to
much on the design of Celix?
Thanx in advance,
---------- Forwarded message ----------
From: Alexander Broekhuis <a....@gmail.com>
Date: 15 April 2011 10:01
Subject: Usage of Apache Portable Runtime in Celix
To: celix-dev@incubator.apache.org
Hi all,
Some while ago I started looking at the usage of APR in Celix.
APR provides an abstraction to OS specific tasks (file io, threading
etc), the use of APR possible makes it a lot easier to port Celix to
different platforms.
Also, APR uses memory pools for allocation and deallocation, this
could make memory management easier.
Memory pools can, for example, be used for:
- each bundle (create during installation, destroy during
uninstallation/shutdown)
- each started component (create during activator create, destroy
during activator stop)
etc.
To be able to make this work, it is important to define the lifecycle
of "objects" in the framework. This makes it possible to keep the
dynamics, but loose all freeing and destroying of allocations
throughout the code.
Of course there are also some issues, mostly concerning with the
target platforms of Celix. One of the goals is to be able to use Celix
in embedded environments. APR currently does provide support for most
uses OSed (linux, windows, bsd, ...) but not for embedded platforms
such as TI's SYS/BIOS (previously named DSP/BIOS).
Maybe (part of) the APR headers can be used to implement it for other platforms.
I would like to know if this is something we can use in Celix, and
maybe if there is someone with more knowledge about APR who can help
look at how APR can be integrated and used.
--
With kind regards,
Alexander Broekhuis
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Usage of Apache Portable Runtime in Celix
Posted by Marcel Offermans <ma...@luminis.nl>.
Alexander,
Why don't you forward or cross post this to the relevant APR lists as well?
Greetings, Marcel
On 15 Apr 2011, at 10:01 , Alexander Broekhuis wrote:
> Some while ago I started looking at the usage of APR in Celix.
> [...]
> I would like to know if this is something we can use in Celix, and
> maybe if there is someone with more knowledge about APR who can help
> look at how APR can be integrated and used.