[PD] variable receive objects?

[Ivica Ico Bukvic]

> -----Original Message-----
> From: Miller Puckette [mailto:msp at ucsd.edu]
> Sent: Tuesday, June 19, 2012 5:11 PM
> To: Ivica Ico Bukvic
> Cc: 'Claude Heiland-Allen'; Hans-Christoph Steiner; pd-list at iem.at
> Subject: Re: [PD] variable receive objects?
> 
> 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).

Thanks for the update, Miller. Is there a way you could give me an example
patch that would fail this way? I ask this simply because I am unable to
imagine one you describe here. Namely, even if a parent's send has been
changed by the child-of-a-child object this way, this change would only make
specific instance point to null object but its pointer would be still valid
until its entire sub-tree has been navigated, and only after its entire
sub-tree has been navigated would it be actually dereferencing stuff and
fixing the pointers accordingly before the next incoming wave of calls.

> 
> 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 :)

You mean declaration of a global variable needs to be placed at the top of
the source file? Sure, that is an easy fix. It's been placed here in
proximity to make the patch more legible.

> 
> 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 :)

I am not so sure there is a performance hit since in both cases
dereferencing happens in exactly the same way, except in this one the
referencing is delayed and in the interim structs destined to be
dereferenced are made to point to null and then skipped if a subsequent call
trips over a null-pointing struct before it has been dereferenced. As such
its performance impact should be minimal.

Best wishes,

Ico

> 
> 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
> > >
> > >
> >