I guess this is mainly for the Pd devs,
Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free.
Initially, I designed a workaround where pd_free is enqueued on the guiqueue and invoked a bit later ensuring that it is called after the tree navigation has ended. This works in most cases but not all. Intermittently this will crash Pd when using Jonathan's Nav abstraction which closes the current patch and also opens a new patch (navigation abstraction would be used to go between help files always keeping only one patch open at a time). Attached is Jonathan's abstraction.
So, now I started investigating further and it seems that canvas_vis(x,0) closes the patch without any problems and without having to delay anything but this is not enough in and of itself to actually deallocate the actual t_canvas x and other instantiated objects associated with the canvas. So, how could one go about to implement this feature?
Ico
Le 2011-11-19 à 11:39:00, Ivica Ico Bukvic a écrit :
Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free.
I don't think that you can actually get out of this problem without something like reference-counting. Or else it's going to be quite hackish.
I think that Pd should get reference-counting on a large scale. This is not a new idea, but I think that I'm the only one to have considered it realistic. This would solve several problems (freeing symbols, etc) and not just this one. But it would require a somewhat different API and ABI than what we have now, which is the big hurdle.
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.
A C++-based header could make the new API feel more like the old one, by impliciting nearly all of the new calls (by redefining t_atom::operator=).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
From: Mathieu Bouchard matju@artengine.ca To: Ivica Ico Bukvic ico@vt.edu Cc: pd-list@iem.at; pd-dev@iem.at Sent: Saturday, November 19, 2011 1:30 PM Subject: Re: [PD] pd_free vs canvas_vis
Le 2011-11-19 à 11:39:00, Ivica Ico Bukvic a écrit :
Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free.
I don't think that you can actually get out of this problem without something like reference-counting. Or else it's going to be quite hackish.
I think that Pd should get reference-counting on a large scale. This is not a new idea, but I think that I'm the only one to have considered it realistic. This would solve several problems (freeing symbols, etc) and not just this one.
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
what other problems could be addressed by reference counting.
But it would require a somewhat different API and ABI than what we have now, which is the big hurdle.
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?
A C++-based header could make the new API feel more like the old one, by impliciting nearly all of the new calls (by redefining t_atom::operator=).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
-
Ivica Ico Bukvic -
Jonathan Wilkes -
Mathieu Bouchard