bug#22737: 25.1; Finalizer should be optional in dynamic modules

[Jess Balint <jbalint@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

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 <eliz@gnu.org> wrote:

> > Date: Tue, 23 Feb 2016 16:47:12 -0600
> > From: Jess Balint <jbalint@gmail.com>
> > 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.
>

[-- Attachment #2: Type: text/html, Size: 2279 bytes --]