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

[IOhannes m zmoelnig]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8T40AACgkQkX2Xpv6ydvRY2QCgjiMPHvSK5OgL5o6TlWk+JVkc
b9gAnjM0qd81axcEpk4aSYH5nRqe2w1A
=O7F+
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120116/4b31a859/attachment.bin>