[PD-dev] per-thread storage in Pd in support of pdlib - discussion?
hans at at.or.at
Sun Jan 15 03:48:01 CET 2012
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.
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];
> 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
> 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?
> Pd-dev mailing list
> Pd-dev at iem.at
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
More information about the Pd-dev