<html><head></head><body>In that case, the patch I attached in my previous email should take care of it with practically no added overhead.<br>
<br>
Best wishes,<br>
<br>
Ico<br>
<br>
Ivica Ico Bukvic, D.M.A<br>
Composition, Music Technology<br>
Director, DISIS Interactive Sound & Intermedia Studio<br>
Director, L2Ork Linux Laptop Orchestra<br>
Assistant Director, CCTAD<br>
Virginia Tech<br>
Department of Music<br>
Blacksburg, VA 24061-0240<br>
(540) 231-6139<br>
(540) 231-5034 (fax)<br>
<a href="http://disis.music.vt.edu">disis.music.vt.edu</a><br>
<a href="http://l2ork.music.vt.edu">l2ork.music.vt.edu</a><br>
<a href="http://ico.bukvic.net">ico.bukvic.net</a><br><br><div class="gmail_quote">Miller Puckette <msp@ucsd.edu> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">I haven't looked at this in detail yet. I don't think there are any worries<br />as to teh caveat at the bottim since as far as I know Pd does nothing<br />asynchronously except for read/writesf~.<br /><br />cheers<br />Miller<br />On Tue, May 29, 2012 at 07:09:28PM -0400, Ivica Ico Bukvic wrote:<br />> Has anyone bothered testing this? It works fine over here as far as I can<br />> see. Also, Miller, I would greatly appreciate your insight on the potential<br />> caveat described below. Namely, is it possible for Pd to execute multiple<br />> paths asynchronously (e.g. one part of the graph is executing something and<br />> at the same time there is a bang button pressed via GUI--in this situation<br />> does the bang trigger second, asynchronous process or is this scheduled<br />> after the previous graph call has completed its navigation?)?<br />> <br />> NB: patc!
h might
require a bit of fuzzy factor since it is based off of the<br />> pd-l2ork code base that is slightly different from the vanilla/extended.<br />> <br />> Ico<br />> <br />> > -----Original Message-----<br />> > From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of<br />> > Ivica Ico Bukvic<br />> > Sent: Monday, May 28, 2012 1:08 AM<br />> > To: Claude Heiland-Allen<br />> > Cc: pd-list@iem.at<br />> > Subject: Re: [PD] variable receive objects?<br />> > <br />> > On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote:<br />> > > Never mind. Just had a look at pd_bind/unbind code. This makes me<br />> > > wonder what if all bindings/unbindings were handled as lists? Would<br />> > > this potentially break anything (other than having to modify<br />> > > bind/unbind mechanism)? Does anything else depend on 2-member list vs.<br />> > > 1-member pointer in !
terms of
bindings? I suspect there would be some<br />> > > cpu impact on having it implemented this way, but not that much.<br />> > ><br />> > Actually, please try attached patch. It fixes all such crashes for me on<br />> pd-<br />> > l2ork. Basically it has a static variable set within m_pd.c that is turned<br />> on only<br />> > when one of bindlist_<var>() functions is called in which case any<br />> potential<br />> > memory deallocation calls within pd_unbind are deferred until all members<br />> > of bindlist->b_list have been served with data. After that<br />> bindlist_cleanup<br />> > does its thing based on which members have e_who pointing to NULL and<br />> > that's that. In the event a call arrives outside those bindlist_<var>()<br />> > functions, it immediately deallocates stuff as is currently the case with<br />> pd<br />> > vanilla and extended.<br />> > <!
br
/>> > Potential caveat: if one somehow invokes an event outside regular<br />> execution<br />> > of the code and it somehow arrives exactly during that narrow span of time<br />> > when the static var is enabled, its memory deallocation will be ignored. I<br />> am<br />> > however unsure if this is theoretically even possible since my<br />> understanding<br />> > is that the graph is never being executed out-of-sync. Please correct me<br />> if I<br />> > am wrong.<br />> > <br />> > Cheers!<br />> > <br />> > --<br />> > Ivica Ico Bukvic, D.M.A<br />> > Composition, Music Technology<br />> > Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork<br />> Linux<br />> > Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech<br />> > Department of Music Blacksburg, VA 24061-0240<br />> > (540) 231-6139<br />> > (540) 231-50!
34
(fax)<br />> > <a href="http://disis.music.vt.edu">disis.music.vt.edu</a><br />> > <a href="http://l2ork.music.vt.edu">l2ork.music.vt.edu</a><br />> > <a href="http://ico.bukvic.net">ico.bukvic.net</a><br />> <br />> <br /></pre></blockquote></div></body></html>