[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

Mathieu Bouchard matju at artengine.ca
Tue Feb 7 23:58:04 CET 2012


Le 2012-01-14 à 13:04:00, Miller Puckette a écrit :

> The question I'd like to rais is this: would it suffice to make Pd 
> instances be per-thread?

This means I'd have to switch threads every time I want to send a message 
to pd. In my app, I have a main thread, and I have a pd-audio thread. The 
message-domain stuff currently runs in the main thread. I use either 
sys_lock or I switch to using a lock that's actually reentrant. This is 
easier than switching threads.

Alternately, message-passing can happen using «mailboxes», but that's more 
complicated, and it means not being able to get an answer from pd right 
now, because it's async.

> Alternatively, one could use the C++11 standard thread_local keyword, 
> although I believe that's not widely implemented yet.

AFAIK, this standard in general is hardly supported at the moment, not 
just the thread_local keyword, and I'd rather have Pd's source start using 
C++83 features before it starts getting into C++11 land.

> To do this I'd replace all globals like static t_symbol 
> *symhash[HASHSIZE]; with PDSTATIC t_symbol *symhash[HASHSIZE];

I'd rather have you put a separate lock inside gensym so that we don't 
have to call sys_lock and sys_unlock just for that. Then that hashtable 
can be shared between instances, in nearly all situations. Saves some RAM 
too.

> 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.

You don't need multiple copies of the cos-table, and you won't ever need.

> 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).

Why is it normal to have one thread per plug-in ? As someone who doesn't 
know VST, this seems weird. Think of Pd as being a plugin interface of its 
own. Pd can schedule all of its plugins in the same thread and it's not a 
problem for working patches. It might be just some kind of 
infinite-loop-protection (a feature that Pd doesn't have).

> or some declspec horror in Miscoroft C.

I don't know that name. Maybe you mean H.P.Lovecraft, which also ends with 
«ft».

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC


More information about the Pd-dev mailing list