[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