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