From celix-dev-return-185-apmail-incubator-celix-dev-archive=incubator.apache.org@incubator.apache.org Mon Jun 4 10:01:17 2012 Return-Path: X-Original-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 22D1B986B for ; Mon, 4 Jun 2012 10:01:17 +0000 (UTC) Received: (qmail 62069 invoked by uid 500); 4 Jun 2012 10:01:17 -0000 Delivered-To: apmail-incubator-celix-dev-archive@incubator.apache.org Received: (qmail 61980 invoked by uid 500); 4 Jun 2012 10:01:14 -0000 Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: celix-dev@incubator.apache.org Delivered-To: mailing list celix-dev@incubator.apache.org Received: (qmail 61946 invoked by uid 99); 4 Jun 2012 10:01:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2012 10:01:13 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of a.broekhuis@gmail.com designates 209.85.160.175 as permitted sender) Received: from [209.85.160.175] (HELO mail-gh0-f175.google.com) (209.85.160.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2012 10:01:08 +0000 Received: by ghbz2 with SMTP id z2so4061154ghb.6 for ; Mon, 04 Jun 2012 03:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UIB9MAEIX5QAChZDSu8U0y4jLBxFgXpMakTFuIwbuHE=; b=rQ+9mgqvLO8GIWHIqx2++3F06kfZxfcr+J7lfLT7Ktvjreo66oFVSYIW4zBtZECL+o o6HazDABZck9BMpi8bc7IZHvgoKLe0ALrhNMdmQ9JUV2DMNNCn0ax2bmEaeFCWhqWkLM hfWSYH6+yZBFPMDkqUC3t+D4ywLveWVfcNnxFK8b8D8FUBd7LyDkjSMH6wdDM01DQhDG rQiCQDTuzn/YxnthE2a43ffRid0WoF/fpc9vVqYC2MGHOQuxBteqkMwmsiL8X8IQ/oNC sluSr1o8QFgSQvLBsLXqmQOuWb8itbGXs7T65sRIeAcxHb0K0irSL9ma020+2HthZQ8u z6VQ== MIME-Version: 1.0 Received: by 10.60.30.101 with SMTP id r5mr11172320oeh.68.1338804047605; Mon, 04 Jun 2012 03:00:47 -0700 (PDT) Received: by 10.182.65.97 with HTTP; Mon, 4 Jun 2012 03:00:47 -0700 (PDT) In-Reply-To: <4FC8C52A.7000604@dkfz-heidelberg.de> References: <4FC8C52A.7000604@dkfz-heidelberg.de> Date: Mon, 4 Jun 2012 12:00:47 +0200 Message-ID: Subject: Re: [Native-OSGi] OSGi API: Allocated memory ownership From: Alexander Broekhuis To: celix-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=e89a8fb20678ae6f5f04c1a29b91 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8fb20678ae6f5f04c1a29b91 Content-Type: text/plain; charset=ISO-8859-1 Hi > I'm not a C - expert, but I think the only viable solution is to > accurately document the lifetime and ownership of pointers. > Well I think this is not a C specific problem, the same applies to C++ I guess. Someone has to free allocated memory. > > For memory owned by the framework, any memory management technique which > guarantees the stated lifetime will do (e.g. APR memory pools). > Since this is "internal" to the framework this can be anything the framework implementation uses. For Celix this is indeed APR. Memory which is to be owned by the caller (user) could probably be > allocated and deleted by using special functions (hooks) provided by each > bundle which use implementation specific routines for memory management. > Otherwise we just state that the returned memory belongs to the caller. > This is the more interesting part of the problem. How would such hooks look like, and doesn't this making bundles awkward? A generic header for this could look like this: memory_hooks.h: int mem_alloc(void *handle, size_t size, void **block); int mem_calloc(void *handle, size_t num, size_t size, void **block); int mem_realloc(void *handle, void *block, size_t size, void **newblock); int mem_free(void *handle, void *block); These function are basically the "normal" C memory functions, does C++ have different/additional ones? I've added a *handle to all of them to be able to pass some "instance" to it. For example, APR would need a memory pool, which can be a member of the instance type/struct. How does the framework get the handle? One additional method could work: int mem_createHandle(void **handle); For APR: mem_alloc -> use apr_palloc(handle->pool, size) mem_calloc -> use apr_pcalloc(handle->pool, size) mem_realloc -> no alternative in APR, implement a solution like [1] mem_free -> not implemented, the user has to clear the pool at some time Looking at it like this, I just realize this solution has a huge drawback when used in combination with APR. For different calls different pools are needed. Using this model, there is only one pool which is used for every allocation. Basically this means the user is not in control of the lifetime of memory. The only solution I can think of is to have the user supply the pool on which the memory has to be allocated, but we don't want this on our API. A possibility would be to supply the handle (instead of the pool) which is used by the memory hooks. For example: int bundle_getEntry(bundle, handle, char *name, char **entry) Instead of letting the framework use handle, handle is simply passed on the the memory hooks and used in a way the caller wants. This also eliminates the need for the createHandle function in the header file. The user can create one when needed. In case of APR, this handle probably can directly be the pool. I hope this still makes sense... [1]: http://marc.info/?l=apr-dev&m=109065999530290&w=2 -- Met vriendelijke groet, Alexander Broekhuis --e89a8fb20678ae6f5f04c1a29b91--