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