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:
- I'm thrilled to see that multiple instances are happening. Thanks,
Miller!
- 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.)
- 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.
- 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?
- 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 danomatika@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-request@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