I don't really have a sense of other possible approaches and their advantages/disadvantages. Couldn't this issue also be solved in the logic of the code? A lot of the current global variables could easily be visible in each thread, and still be fully functional. Things like sys_libdir and the like. So it doesn't seem like all global vars are the issue.
.hc On Jan 14, 2012, at 4:04 PM, Miller Puckette wrote: > To Pd dev - > > For some time the good folks who brought us pdlib have been asking how > one could make it possible to run several instances of Pd in a single > address space. > > The question I'd like to rais is this: would it suffice to make Pd instances > be per-thread? This could be done by going through all the source and > modifyin global and static variables with the nonstandard __thread > leyword (gcc) or some declspec horror in Miscoroft C. Alternatively, > one could use the C++11 standard thread_local keyword, although I believe > that's not widely implemented yet. > > To do this I'd replace all globals like > static t_symbol *symhash[HASHSIZE]; > with > PDSTATIC t_symbol *symhash[HASHSIZE]; > > and define PDSTATIC to static (also PDGLOBAL to the empty string and > PDEXTERN to extern). Then anyone wanting to come along and recompile pd > to work per-thread only has to redefine the three appropriately to the > compiler. > > Here are the gotchas I can foresee: > > 1. external objects making explicit references to global storage > (such as canvas_dspstate and cos-table in m_pd.h and much stuff in the more > 'private' header files) would have to be recompiled to run per-thread. They'd > still work fine with vanilla Pd. > > 2. existing externs that create threads would break at the source level if > they use any Pd-supplied functions at all (outlet_bang(), clock_set(), > gensym(), etc) in 'other" threads. Again they'd still work in Pd vanilla, > just not with versions of Pd recompiled to run per-thread. > > 3. lots of lines of code would be touched and this might make a number of > existing patches fail to apply cleanly. > > 4. supposing you use this to make a VST plug-in: what would happen if some > stupid host app called all its VST plug-ins from the same thread? (I > think it's normal for hosts always to make a new thread for every VST > plug-in instance but I don't know if this is universal). > > 5. If you wanted to run two instances of Pd in the same thread this wouldn't > help. You'd have to spawn new threads and pass control to them to get into > the alternate Pds. > > Comments anyone? > > thanks > Miller > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev ---------------------------------------------------------------------------- I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev