Short answer: I started discovering that there were static structures in Pd that had ponters to symbols - all such static structures would have to be tracked down and made per-instance.
Longer one: The specific one I hit (but this could be only one of many problems hiding there) was every single static t_class (one per class). This structure containes a list of symbols (message selectors) and associated function pointers (and more). At first I thought, no problem, we'll just create one trigger_class (e.g.) per Pd nstance by calling all the init methds anew for each new Pd instance. But that failed miserably because: t_trgger *x = pd_new(trgger_class) then blithely picks up the most recently created trgger_class and not the instance-specfc one. That new one then can't find any messages because it has teh symbols fro mteh wrong PD instance to check against. I thought of perhaps changing the class structure itself to keep track of which instance we're in, but couldn't fgure out how to do it without requiring a hash list lookup on each message pass in Pd (ugh) or by making incompatible API changes. And this might just be the tip of an iceberg - I have no idea what other oopses I'd discover after coding all that up. cheers M On Sun, May 25, 2014 at 11:42:07PM -0400, Peter Brinkmann wrote: > Hi everybody, > Sorry to chime in so late in the conversation... > > Here's my take on the discussion so far: > > 1. I'm thrilled to see that multiple instances are happening. Thanks, > Miller! > > 2. If at all possible, we should go all the way and have fully independent > instances. Anything else will likely come back to bite us, by requiring > additional documentation and other support, confusing developers (and > therefore giving rise to bugs), underutilizing multicore systems, excluding > use cases that we haven't thought of yet, etc. (And I already have a few > use cases where concurrent instances would have been handy.) > > 3. As I understand the current state, there are two problems that we need > to solve to achieve independent instances. One is a revision of the API to > introduce an additional instance parameter. That might be unpleasant to > implement but seems feasible. (I always expected that we'd need a > completely revised libpd 2.0 when multiple instances become available.) The > other one is the shared symbol table. > > 4. Miller, you said in your original post that you ran into seemingly > insoluble problems when trying to create per-instance symbol tables. Would > you mind elaborating on this point? > > 5. Even if we're stuck with a single global symbol table, we may be able to > make it thread-safe without having to resort to locks. > > Cheers, > Peter > > > > On Thu, May 22, 2014 at 5:24 PM, Dan Wilcox <danomat...@gmail.com> wrote: > > > Sure. I guess I don't know what I'm saying :D other than the question: > > what do we reasonably need? Does the current solution work or is the next > > step required? > > > > On May 22, 2014, at 5:03 PM, pd-dev-requ...@lists.iem.at wrote: > > > > To me, I think the ultimate use case is to be able to fire up two versions > > of pd in the same processing chain (take vst's in a DAW for example), load > > each one with identical patches, and have them controlled separately. This > > would be a fantastic boost for the ability to extend what we can already do > > with Pd as an audio processing engine, separated from its native GUI. > > Locking may be necessary in places, but then that is extremely fast these > > days. > > > > Of course, this all leads to the pdinstance being able to manage the > > symbol table along with Miller's recent changes, but what are the > > difficulties in achieving this? It seems like Miller tried and it was more > > difficult than what we are imagining. > > > > cheers, > > Rich > > > > > > -------- > > Dan Wilcox > > @danomatika > > danomatika.com > > robotcowboy.com > > > > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev@lists.iem.at > > http://lists.puredata.info/listinfo/pd-dev > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
