[PD-dev] array/table and canvas memory management

[Christof Ressi]

Hi,

> So my question is: if I allocate an array/table in an external, do I 
> have to manage its de-allocation or is there some sort of reference 
> counter?

A graphical array always belongs to a canvas and it will be 
automatically be destroyed when the canvas is freed. Destroying a single 
graphical array in code is a bit tricky and you need stuff from private 
headers like g_canvas.h.

> How about with canvases?
> If I create a canvas per analysis data set, do I have to manage the 
> canvas de-allocation?

This is how you create a private canvas in the object constructor:

pd_vmess(&pd_canvasmaker,gensym("canvas"),"iiiii",0,0,100,100,10);
x_canvas =(t_canvas*)s__X.s_thing;

pd_vmess((t_pd *)x_canvas, gensym("pop"),"i",0);

Such a canvas will have an owner, but it doesn't actually belong to a 
glist, so you have to free it yourself in the destructor:

pd_free((t_pd *)x_canvas);

Note that if you want to create a table outside the object constructor, 
you should cache the current canvas with canvas_getcurrent() in the 
constructor. Before creating a new canvas you have to push the cached 
canvas with pd_push() or canvas_setcurrent() and in the end pop it with 
pd_pop() or canvas_unsetcurrent(). This makes sure that the canvas gets 
an owner and doesn't go to the root canvas list.

> If I de-allocate an array (inside a canvas I create in code or not) 
> and some other object is using that array, what happens?

A crash :-) Unless the object uses a gpointer, so it can check whether 
the glist is still alive.

I just want to stress that managing canvasses/garrays programmatically 
is not officially supported by the Pd API. It's possible with the 
workarounds shown above, but I wouldn't recommend it unless it's 100% 
necessary.

---

> I'd like to be able to load several sets of tables with a single 
> object, and then access that data with an arbitrary number of 
> resynthizers.

You might reconsider whether you really need actual Pd tables to do 
this. I think you only need them if the data should be accessible as 
tables outside your own externals. Otherwise I would strongly recommend 
to use your own private data structure and share it among your externals.

Just create a faux-class like this:

static t_class *data_class;

typedef struct _data {
     t_pd d_pd;
     // your data..
} t_data;

// in the setup routine:
data_class=class_new(gensym("data private"),
0,0,sizeof(t_data),CLASS_PD,0);

There's no need to (de)allocate instances with pd_new()/pd_free(), you 
can just do getbytes()/freebytes(), but you have to make sure to set 
d_pd to data_class. See the "alist" class in x_list.c.

Because t_data is a Pd class, you can now safely bind instances to 
symbols with pd_bind() and retrieve instances with pd_findbyclass().

As you can see, this allows you to easily share custom data structures 
across externals. This is also safe as long as you always access the 
data through the symbol with pd_findbyclass(). It will return NULL if 
the data has been unbound (and deleted).

This means you can have an object similar to [array define] which 
creates a t_data instance and binds it to a symbol. In your patch you 
can pass this symbol to your other externals which can retrieve the data 
and do something with it.

Christof

On 27.01.2020 19:54, x nor wrote:
> I'm working on an external that loads analysis data into tables for 
> use in re-synthesis and I want to make sure I'm not going to be 
> leaking memory with this approach.
>
> I'd like to be able to load several sets of tables with a single 
> object, and then access that data with an arbitrary number of 
> resynthizers.
>
> So my question is: if I allocate an array/table in an external, do I 
> have to manage its de-allocation or is there some sort of reference 
> counter?
>
> How about with canvases?
> If I create a canvas per analysis data set, do I have to manage the 
> canvas de-allocation? If I de-allocate an array (inside a canvas I 
> create in code or not) and some other object is using that array, what 
> happens?
>
> Thanks,
> Ale
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200128/3f0ddb2b/attachment.html>