Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of a.broekhuis@gmail.com
 designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPhv5g9WfRHN-8QBZ4CHf2mPj1pHCRZA30OKzv-XcXSzFoyHgw@mail.gmail.com>
References: 
 <CA+T-u8c4Euzf1sAGOuNjPnW-8jxZ3=FLQLBYTbCyfWiBihBT3Q@mail.gmail.com>
	<CAPhv5g9WfRHN-8QBZ4CHf2mPj1pHCRZA30OKzv-XcXSzFoyHgw@mail.gmail.com>
Date: Fri, 27 Sep 2013 08:22:03 +0200
Message-ID: 
 <CA+T-u8cU7aerM2rARQN2+AzceZDg3B4wqNWMCTdvK9kWNC9oZw@mail.gmail.com>
Subject: Re: [DISCUSS] APR Usage
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11c37aba3a3fc304e7578104

--001a11c37aba3a3fc304e7578104
Content-Type: text/plain; charset=ISO-8859-1

Hi,


2013/9/26 Pepijn Noltes <pepijnnoltes@gmail.com>

> Hi All,
>
> To be honest I see two discussion
>
> 1) Do we want APR with Native-OSGi ?
> Here I can be short. No. APR is not a standard and not a de facto
> standard, because it is not that heavily used, ss result it should not
> be in a standard API spec.
>

While this isn't an official Native-OSGi channel I think it is save to
assume this to be true.


>
> 2) Is APR - and more specifically APR pools - the right solution for a
> OSGi approach in C.
> Here is disagree. Personally I like apr pools and IMO it helps
> organising big chunks of work and the memory needed for that. I agree
> that it is oriented around the request and handle workflow, but there
> is support for unmanaged pools and unmanaged pools could be used to
> swap ownership. I also think that it is the responsibility of the
> services that need to give away ownership of memory to arrange that in
> the service API. APR pools can be used for, but is not needed and up
> to the developer of the service.


While unmanaged pools might be helpful, I do wonder if it is the right
thing to do. Since it is still a pool, and still part of APR, meaning that
if a service wants to give away ownership it still isn't possible to only
pass a pointer. It would still need to pass a pool as well, which then has
to be cleared by the receiving end.

Here I do really miss a function to take a pointer from a pool and simple
make it a unmanaged pointer (even one level lower then an unmanaged pool).


>
> I think ownership in C will always be difficult, we don't have a
> garbage collection or reference counters and we have to think in
> ownership. I more worried that for the Java OSGi API there isn't
> always a good mapping.
>

We (Celix and Native-OSGi) should come up with a clever mapping and detail
this in the spec and docs.. But I agree, this is a difficult thing to do,
simply following the Java-OSGi pattern won't be enough. A clear example of
this is how Celix handles Service References.


>
> For example the problem we ran into was the a bundle A looked up a
> service reference and forwarded this to bundle B. But when bundle A is
> removed the allocated memory for that service reference was removed
> and bundle B had a bogus service reference. Hard bug to find, easy to
> fix.
> This was in the RemoteServiceAdmin and the Java API is
> exportService(ServiceReference reference,
> java.util.Map<java.lang.String,java.lang.Object> properties)
> But I think i C we should not never forward a service reference, but
> provide the serviceId.
>

While this analysis sounds ok, IMHO you are ignoring the bigger picture
here. This example is only one symptom and not the root cause.. The problem
is that any memory allocated by bundle A on its own pool, which is then
passed to bundle B is a problem. Instead of looking into a solution per
symptom, we need a solution for the bigger picture.

Also, why shouldn't we forward service references? It sounds like a
restriction being imposed on a user because we want to use memory pools.
>From a conceptual point of view I can't think of any reason why this
shouldn't be done. Again, I keep coming back to APR not being able to
take/add a pointer from/to a pool..
If we start imposing such restriction, where does it end? Let's say bundle
A get a file pointer to any file on a system, and then passes this pointer
to bundle B. Stopping/uninstalling bundle A doesn't mean the file is gone,
but the pointer is invalidated.. What should bundle A pass? A char on the
stack and an API warning that the receiving end has to copy it to its own
memory space? While this works, it is again symptom fixing, and imho a
fuzzy solution for the users...


>
> But in conclusion if we want to support Native-OSGi I think we should
> drop APR pools in API.
>

I agree, but an important thing to note here is that even though APR
shouldn't be visible on the API, it still is possible to use it internally.
So for the internal stuff Celix could use APR, on the edges (the public
API) everything being passed to the caller should be "normal" memory. This
gives a mix of pools and malloc/free. Not sure if that is a wise thing to
do...

-- 
Met vriendelijke groet,

Alexander Broekhuis

--001a11c37aba3a3fc304e7578104--