defining PDINSTANCE and PDTHREADS in libpd - Pd-dev

17 Apr 2017


      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.