From celix-dev-return-196-apmail-incubator-celix-dev-archive=incubator.apache.org@incubator.apache.org Tue Jun 5 18:43:30 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 30E9AC411 for ; Tue, 5 Jun 2012 18:43:30 +0000 (UTC) Received: (qmail 94841 invoked by uid 500); 5 Jun 2012 18:43:30 -0000 Delivered-To: apmail-incubator-celix-dev-archive@incubator.apache.org Received: (qmail 94821 invoked by uid 500); 5 Jun 2012 18:43:30 -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 94812 invoked by uid 99); 5 Jun 2012 18:43:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2012 18:43:30 +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 (nike.apache.org: domain of a.broekhuis@gmail.com designates 209.85.213.47 as permitted sender) Received: from [209.85.213.47] (HELO mail-yw0-f47.google.com) (209.85.213.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2012 18:43:22 +0000 Received: by yhjj56 with SMTP id j56so4211239yhj.6 for ; Tue, 05 Jun 2012 11:43:01 -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=leN+GrBQzcvHKl9kAD/WSOEOWHLPSeVLG0gAWTx4huI=; b=cjsPP/N9OreIDAt8bZo5RpVwLf/jBnUqFDhR809tSnj7p1Zt3MtbPIj6w5MPTxkHfW UhO7P+csTy0GNwJuea9hJb+4JjohfR9pTtDroueaDqS1sPJ3n/l8qUiGX6oz7ZqIQ/6k TFqyRsTNyFJwVDUX1/B5HuOQ2pr9h114jlrJnYP536/hNEO1XfETB+zPNNss3FQshroO a1HJLXUcgKU40VfndRwoAnGtUMYXoH8b/cARnAT9UTB5hD33ATiaWJeyuDjipiBFORUC MXV+Ih7fOrJ4bPLbwdl2f5Pcrc3TJJVp2Cpx4lIbB3Oegt4/eTYS60afMlTdi7GqilJP ox1g== MIME-Version: 1.0 Received: by 10.60.28.162 with SMTP id c2mr17755668oeh.3.1338921781171; Tue, 05 Jun 2012 11:43:01 -0700 (PDT) Received: by 10.182.65.97 with HTTP; Tue, 5 Jun 2012 11:43:01 -0700 (PDT) In-Reply-To: <4FCE387D.9030304@dkfz-heidelberg.de> References: <4FC8C52A.7000604@dkfz-heidelberg.de> <4FCE387D.9030304@dkfz-heidelberg.de> Date: Tue, 5 Jun 2012 20:43:01 +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=e89a8ff1c7622614ba04c1be05ff --e89a8ff1c7622614ba04c1be05ff Content-Type: text/plain; charset=ISO-8859-1 Hi, > So bundles could use different pools for different API calls. Maybe that > kind of flexibility is enough... If there is no bundle specific "mem_alloc" > function, the framework could fall back to usual malloc/free calls. Does > that make sense? This still ties the user to a fixed lifetime for pools, still leaving the possibility for unneeded memory growth. The user should be in absolute control of the memory and when it has to be cleared. So for each call (similar or not) it can decide how to handle the memory. Tying it to a function still is a rather fixed solution. I'm with Pepijn on this one, user the regular "malloc" and let the user "free" it is the best for now I think. -- Met vriendelijke groet, Alexander Broekhuis --e89a8ff1c7622614ba04c1be05ff--