[PD] pd_free vs canvas_vis

[Mathieu Bouchard]

Le 2011-11-19 à 11:47:00, Jonathan Wilkes a écrit :

> Could you go a little into the "etc." here?  My particular use case is a 
> bit too narrow to justify large-scale changes, and I'm curious

If A_POINTER uses reference-counting, then there will be no more « stale 
pointers », as data will be kept for as long as necessary until the 
pointers are gone, even though the data might no longer visible in a 
patch.

There aren't many different cases for the «etc» because there aren't many 
(standard) datatypes in Pd. But A_SYMBOL refcount is a big deal in several 
ways, because they're used both for send/receive and for text, two uses 
that are usually quite different from each other but that can each be a 
strain on the symbol-table (both the speed of gensym and the ram usage).

For future types, however, refcounting would be useful for turning binbuf 
into an atom type (named A_BINBUF or A_LIST or whatever else). It could 
also become more inviting for adding various other custom datatypes (from 
OpenCV, STL, PDP, A_BLOB, GF, and future things).

Reference counting is similar to what many programming languages do, and 
it's also what the UNIX filesystems do : if you open a file in Linux 
(using fopen() and no fclose() yet) then you can keep on reading/writing 
it until all fopen() calls get a matching fclose() or equivalent (exit(), 
or a reboot+scandisk). That's unlike what I remember from Windows, in 
which you can't delete the file because it's «busy».

>> The new API would require only adding function calls to the source, to mark which pointers are still potentially in use. The new API could compile to either the new ABI or the old ABI using header tricks.
> Does that mean you could compile Pd to use old externals (basically everything at present), or new (future) externals, but not 
> both?

Well, it depends on how much effort is done at runtime to conciliate them. 
It could be made so that old externals can run in new Pd at the cost of 
giving up refcount on anything that those externs touch, and perhaps a 
bigger runtime cost (because adding one more case at each time you 
decrease the count, and one more case each time you send a message).

But overall, even changing all externals is a lot simpler than trying to 
organise a mark-sweep real-time collector that does not suck (think of all 
the RAM usage of Java... wait, don't !).

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC