From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jess Balint Newsgroups: gmane.emacs.bugs Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules Date: Fri, 26 Feb 2016 10:17:26 -0600 Message-ID: References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c39aa6884fdd052caea2f1 X-Trace: ger.gmane.org 1456503502 14119 80.91.229.3 (26 Feb 2016 16:18:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 16:18:22 +0000 (UTC) Cc: 22737@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 17:18:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZL5m-0004Np-DK for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 17:18:10 +0100 Original-Received: from localhost ([::1]:50878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZL5l-0001JW-Mq for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 11:18:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZL5h-0001JO-Dt for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 11:18:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZL5e-0002AA-5z for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 11:18:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZL5e-0002A6-2p for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 11:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZL5d-0007lK-Sd for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 11:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jess Balint Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Feb 2016 16:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22737-submit@debbugs.gnu.org id=B22737.145650345329803 (code B ref 22737); Fri, 26 Feb 2016 16:18:01 +0000 Original-Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 16:17:33 +0000 Original-Received: from localhost ([127.0.0.1]:47823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZL5B-0007kc-Jm for submit@debbugs.gnu.org; Fri, 26 Feb 2016 11:17:33 -0500 Original-Received: from mail-ig0-f169.google.com ([209.85.213.169]:36297) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZL5A-0007kP-30 for 22737@debbugs.gnu.org; Fri, 26 Feb 2016 11:17:32 -0500 Original-Received: by mail-ig0-f169.google.com with SMTP id xg9so37636796igb.1 for <22737@debbugs.gnu.org>; Fri, 26 Feb 2016 08:17:32 -0800 (PST) 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 :cc; bh=vk1aqQwZQplQ+eJz/rL6i90USMAtDY7EbYyhEIW+Ej8=; b=E/ts5G6ihT5wnLHRW6TbQBzIrrHn2301sQ11jZ9oLDyLCFncA5dhEfTcCoNPreKz0j lDn3I964w7uV/xYzXkPEZrEUC0Wkar8eo0k1Tv1EOFRBNg3zM+9pzjXLc4tXnOEzYqcy t60WojnpBvE+FP7r4iIVvZbLs9nSDZGvTBVpBE7OViBcWbS1zTNeJu1t5VvhHt3PcIKQ OlVTpImUHGYjWSUWUXx0r+NrZw8l4zS6n4bVOHRlE4UOsY0PMnncVDemYolCgVpZQAMl TM9kfOO3vxrKdGvSZnE7JoZZdPwitL9ZNy/APAAtHKPZb//SfjDWDFWNE7Z3nHqCI1e6 xhYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vk1aqQwZQplQ+eJz/rL6i90USMAtDY7EbYyhEIW+Ej8=; b=bjZDsEd0qRROqQH6N9qMdSAJARHX3QeS15ejtPIQY+84zV3SYwBfqxgUIZvEm3Npm3 3acjgoxR7AEcyuIYxUoTwRHlmASpoyTAHSbJkNOcArcXtCiEPd3OTiwcivuUrYSnl9lY YPuifoQPCw8o+AylJnWAOKFlup0KdAsnLtMPIMSf3WREM5sZY7QdY+GYU3X7uQYFgJgL cpQCUbeuyLafgCvfnOoa+znOejmbIyFV6Uz1q/NscllhewLSm/tHVrmEZOAQT9dNsxXf 1RTGyXctLd75PhUksx3aZVGnNIqWgc/GtiZSNfkPnKjKUrlrOsPZ0Vr5Cp/wTLoEh9v9 HZ9w== X-Gm-Message-State: AD7BkJLgo21kvGtiQ20Gntbu68kt1Ckz3aZ+RuoAPfbLnYTyazYAUoVp74Nt5Nb8JNjjVCCyiZJh8AEolWWnJA== X-Received: by 10.50.225.106 with SMTP id rj10mr3001081igc.23.1456503446324; Fri, 26 Feb 2016 08:17:26 -0800 (PST) Original-Received: by 10.64.223.105 with HTTP; Fri, 26 Feb 2016 08:17:26 -0800 (PST) In-Reply-To: <83fuwiixnm.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113896 Archived-At: --001a11c39aa6884fdd052caea2f1 Content-Type: text/plain; charset=UTF-8 Situation #1 - globals: I have pointers to data that are global (not on the heap). I return these pointers from module functions so that they may be used as parameters to other module function calls. These pointers should *never* be freed. In this case I need to supply a no-op finalizer when creating the user pointer. Situation #2 - manual memory management: I have heap-allocated structures whose memory should not be managed by Emacs. I may return pointers to this data one or many times from module calls. The data should be freed only when explicitly requested. I may return many user pointers to the same heap-allocated structure. Even when all these are freed by Emacs, I still retain a pointer in my module which may be returned in a future module call. Again, I'm required to supply a no-op finalizer when creating these user pointers. Thanks. Jess On Tue, Feb 23, 2016 at 9:40 PM, Eli Zaretskii wrote: > > Date: Tue, 23 Feb 2016 16:47:12 -0600 > > From: Jess Balint > > Cc: 22737@debbugs.gnu.org > > > > If the data is unspecified it doesn't *necessarily* need to be freed. If > I return a pointer to some global data then > > I need to create a no-op finalizer just to please this GC code. In some > cases I will be managing memory a bit > > more manually and don't care to have Emacs doing anything for me. > > I don't think I follow. How can you manage memory manually when Emacs > does GC whenever it feels like it? The memory of the objects it GCs > will simply be leaked if you don't have a finalizer. > > Can you describe a specific use case where a finalizer would not be > needed? > > Thanks. > --001a11c39aa6884fdd052caea2f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Situation #1 - globals:

I have pointers= to data that are global (not on the heap). I return these pointers from mo= dule functions so that they may be used as parameters to other module funct= ion calls. These pointers should *never* be freed. In this case I need to s= upply a no-op finalizer when creating the user pointer.

Situation #2 - manual memory management:

I h= ave heap-allocated structures whose memory should not be managed by Emacs. = I may return pointers to this data one or many times from module calls. The= data should be freed only when explicitly requested. I may return many use= r pointers to the same heap-allocated structure. Even when all these are fr= eed by Emacs, I still retain a pointer in my module which may be returned i= n a future module call. Again, I'm required to supply a no-op finalizer= when creating these user pointers.

Thanks.
<= div>
Jess


On Tue, Feb 23, 2016 at 9:40 PM, Eli Zaret= skii <eliz@gnu.org> wrote:
>= Date: Tue, 23 Feb 2016 16:47:12 -0600
> From: Jess Balint <jbalint@gma= il.com>
> Cc: 22737@debbugs.gnu.org=
>
> If the data is unspecified it doesn't *necessarily* need to be fre= ed. If I return a pointer to some global data then
> I need to create a no-op finalizer just to please this GC code. In som= e cases I will be managing memory a bit
> more manually and don't care to have Emacs doing anything for me.<= br>
I don't think I follow.=C2=A0 How can you manage memory manually= when Emacs
does GC whenever it feels like it?=C2=A0 The memory of the objects it GCs will simply be leaked if you don't have a finalizer.

Can you describe a specific use case where a finalizer would not be
needed?

Thanks.

--001a11c39aa6884fdd052caea2f1--