Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?
I accidentally send my mail direct, instead of to the list, so now to the list again. > >> > Please do the smart thing and use them from the start. Saves you a lot >> of trouble later on. Using >> > the FindModules probably makes the build work for more then 80% on >> other platforms from the start. >> > Also using standard stuff gives you less custom CMake scripts to >> maintain. >> > >> > > That's my plan, except when I find things that don't appear workable, such > as no cmake-bundled FindXXX for some project. (Over time maybe we need > build up our own libraries, but I don't have enough time for that at > present.) > Good to hear. In the case CMake doesn't have a bundled find file, often something can be found on other projects. On the other hand, making an own Find module is straightforward and simple if only the library and headers are needed (most likely enough to start with). > > So far OpenSSL, Expat, and LibXml2 seem very easy to deal with on Windows > based on the cmake-bundled FindXXX packages. > Good the hear, there is a big chance the CMake script will work on other platforms as well. Do you also intend to use CMake for project file generation? -- Met vriendelijke groet, Alexander Broekhuis
Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?
If you need someone testing the CMake stuff, feel free to ping me. While I don't have much time, I have experience with CMake in the Celix project. 2013/8/21 Jeff Trawick > On Tue, Aug 20, 2013 at 10:12 PM, William A. Rowe Jr. > wrote: > >> On Tue, 20 Aug 2013 15:47:46 -0400 >> Jeff Trawick wrote: >> >> > I plan to spend some time tilting at that windmill starting later this >> > week, for the purposes of getting a flexible build on Windows. >> > Enough time to get something working? Dunno :( >> >> Feel free to attack it from either angle, once we have a unix or >> a windows starting point, the rest is straightforward. >> >> I've looked some at what it will take. Was going to use what the >> pcre project has done as a starting point. >> > > Yeah. I had looked at that very briefly before, but after staring at that > some more today and spending a couple of hours starting a spec for APR > trunk, I'm very happy with my progress. I hope to have the core library > and test suite building today. > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > -- Met vriendelijke groet, Alexander Broekhuis
Threads pthread_self
Hi all, I was wondering if there is an APR equivalent for pthread_self()[1] Thanks in advance, [1]: http://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_self.html -- Met vriendelijke groet, Alexander Broekhuis
apr_dso_load with RTLD_LAZY and RTLD_LOCAL
Hello, Currently there is only apr_dso_load which loads libraries globally (RTLD_GLOBAL) and resolves everything direct (RTLD_NOW). Is there an alternative for which I can define the flags myself? The documentation of 1.4 states: Bug: We aught to provide an alternative to RTLD_GLOBAL, which is the only supported method of loading DSOs today. Some progress on this? Thanks in advance -- Met vriendelijke groet, Alexander Broekhuis
Re: Creating a pool returns a previously created instance
Hello, In reply to my own mail, I have found the problem. There was a duplicate apr_pool_destroy which resulted in this unexpected behavior. All works as expected now :). On 17 May 2011 18:36, Alexander Broekhuis wrote: > Hi, > > I have a problem with APR which is related to creating pools. > > In my software (Apache Celix), a library can be loaded/unloaded at > runtime. Before the library is loaded, I create a memory pool to use > by the loaded library. After unloading a library, the pool gets > destroyed. > In a test scenario I have two libraries which are almost identical. > When starting the framework and loading the libraries for the first > time, each library gets an own pool, which is what I expect to happen. > But on a second load (after unloading the 2 libraries), they both end > up using the same pool, which in turn result in unexpected behavior. A > palloc returns a pointer to an already allocated block of memory. > > I tried reproducing this in a smaller example, but haven't succeeded > yet. What did work was removing the apr_pool_destroy after the > unloading. The result of this is that for each load a new pool is > created. Of course this isn't a solution, because the old pool still > uses memory. > > Is there some thing going on with the creation of pools which might be > a problem in this case? Maybe some optimization? If so, can I force > APR to create an actual new pool? > > Thanks in advance, > > -- > Met vriendelijke groet, > > Alexander Broekhuis > -- Met vriendelijke groet, Alexander Broekhuis
Creating a pool returns a previously created instance
Hi, I have a problem with APR which is related to creating pools. In my software (Apache Celix), a library can be loaded/unloaded at runtime. Before the library is loaded, I create a memory pool to use by the loaded library. After unloading a library, the pool gets destroyed. In a test scenario I have two libraries which are almost identical. When starting the framework and loading the libraries for the first time, each library gets an own pool, which is what I expect to happen. But on a second load (after unloading the 2 libraries), they both end up using the same pool, which in turn result in unexpected behavior. A palloc returns a pointer to an already allocated block of memory. I tried reproducing this in a smaller example, but haven't succeeded yet. What did work was removing the apr_pool_destroy after the unloading. The result of this is that for each load a new pool is created. Of course this isn't a solution, because the old pool still uses memory. Is there some thing going on with the creation of pools which might be a problem in this case? Maybe some optimization? If so, can I force APR to create an actual new pool? Thanks in advance, -- Met vriendelijke groet, Alexander Broekhuis
Re: Usage of Apache Portable Runtime in Celix
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
Fwd: Usage of Apache Portable Runtime in Celix
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 Date: 15 April 2011 10:01 Subject: Usage of Apache Portable Runtime in Celix To: celix-...@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
