[PD] variable receive objects?

[Miller Puckette]

I don't think your patch works in every case (I think you simply
have to check every e->e_who inside functions like bindlist_bang()
before dereferencing them since someone could clear one of them while
inside a previous one).

Also, there are declarations after functional lines, e.g., 

+	change_bindlist_via_graph = 1;
     t_bindelem *e;

which is not standard C - something I frequently have to clean up in people's
patches :)

I think something like what you proposed could work; there would still be
a performance hit which I'd probably want to measure before committing to doing
this... since after all we're just talking about a wierd and obnoxious 'feature'
in IEMGUIs that I would simply take out if I could :)

cheers
Miller



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