-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i think there are 2 use cases for multi "threading".
#1 access a single instance of (lib)pd from multiple threads #2 allow multiple instances of (lib)pd to co-exist in global memory.
right now, only #1 is possible at all and it takes some effort on the "thread host" (the external) to not fuck Pd's heap. i think Pd should be more helpful in this respect: a way to make Pd thread-safe is to eliminate global variables and if they can't (or shan't) be eliminate them properly protect them against parallel access.
On 2012-01-14 22:04, Miller Puckette wrote:
To do this I'd replace all globals like
what is wrong with eliminating all directly accessible globals from the API (like "pd_objectmaker") and provide accessor functions to get (thread safe) access to them?
e.g. i would prefer if the symhash stayed global and instead access to it (via gensym()) was thread safe.
i guess the main reason for not doing this is performance(?)
otoh, the subject indicates that you are more talking about case #2. in this case what is needed is to replace the global state by a per-instance state. i would rather _not_ tie the concept of "instance" to the concept of "thread" (even though in practice they might often be interchangeable).
afaik, the usual way to accomplish a concept of multiple instances is to aggragate all currently global variables into a "context" and extend the API so that each function has an additional parameter for this context. this will obviously break API compatibility... a possible workaround would be to add a new function "t_pdcontext*make_current(t_pdcontext*)" that would change the running instance and all API calls would henceforth work on the current context. this would still need a global variable (the current context). the "make_current" call could update the legacy global variables to contain the "current" values. (this would only work as long as no code caches the values of these variables).
of course this doesn't really solve the problem of concurrent access to multiple instances of (lib)pd. in this case an extended API that has an explicit reference to the currently used API should help.
anyhow, i would strongly suggest not to use some compiler magic that might or might not be supported for older (and newer) compilers available on the market for (lib)pd itself. e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?) is supported only by fairly new compilers (and afaik, that support is only partially, even on g++)
fgasdr IOhannes