To pd-dev (but mostly libpd gurus) -
I've pushed a first cut at thread-enabling Pd. I think this feature will be mostly useful within the context of libpd. There are things to worry about...
For instances to work at all, it's necessary to compile Pd code with -DPDINSTANCE . This sets Pd up so that it makes separate symbol tables per Pd instance. This took some surgery, since classes now have to have separate symbol-to-method lookup tables per Pd instance. If the Pd submodule is updated in libpd, libpd won't compile unless the Pd source is compiled with -DPDINSTANCE.
Thread=safety is enabled by default (I'm not sure this is the best idea but that's the way of it for now). To disable it one could compile Pd with the additional dlag -DPDTHREADS=0 . OTOH, to embrace it, it will be necessary to protect every call into Pd with sys_lock() and sys_unlock() calls, even if there's only one thread, because of the following...
...
The thread safety mechanism of Pd has two levels, one of which is to put an exclusive lock (pthread_mutex_t) on each instance of Pd . This is obtained by calling sys_lock() after setting pd_this to the desired instance via pd_setinstance() .
THEN, there's a non-exclsive-readable, exclusive-writable lock protecting all the classes and Pd instances, which Pd itself manages. sys_lock() obtains read-only permission to this lock, and finctions like class_new() within Pd release the real-only access in order to obtain exclusive write access. If read access wasn't in effect, Pd calls "bug("pd_globallock")" to warn you, but in this case Pd will inappropriately re-obtain the lock for read access, so soe later attempt to get exclusive access will likely then deadlock.
The code is in s_inter.c; search for "PDTHREADS".
...
Yet to be done: if this model looks OK, the next thing is to fix the GUI code to be per-instance and thread-safe; this will entail moving the many static variables in g_editor.c, g_template.c and elsewhere into the t_editor structure to make them per-canvas. There are other static variables floating around, some of which are OK to remain static, but some of which will need also to be made per-canvas or per-Pd-instance. It might take a while to track them all down and there might not be any way to verify that everything has been made truly thread-safe.
In any event, as long as nobody is using Pd's GUI for more than one instance of Pd within libpd it should be safe as far as I know. I don't think the official libpd even supports sprouting the GUI yet, so this might be only of interest to me (I've been using libpd with GUI for a very strange project of my own).
Your feedback on all this would be most welcome...
cheers Miller
P.S. I should make a pull request to libpd to add the necessary -DPDTHREADS to the makefile and sys_lock(), sys_unlock() wrappers wherever libpd calls Pd - I'll try to get this together tomorrow.