Miller Puckette <msp@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: patc!
 h 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@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of
> > Ivica Ico Bukvic
> > Sent: Monday, May 28, 2012 1:08 AM
> > To: Claude Heiland-Allen
> > Cc: pd-list@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-50!
 34
(fax)
> > disis.music.vt.edu
> > l2ork.music.vt.edu
> > ico.bukvic.net
> 
>