[PD] threadsafe multi-instance Pd?

Miller Puckette msp at ucsd.edu
Mon Jan 2 00:31:51 CET 2017

To Pd List,

Here's my promised followup mail on Pd thread-ability (the hoped for
ability to call Pd instances, via pdlib, from separate threads concurrently).

Peter Brinkmann made a suggestion during the Pd convention round-table
discussion that I'll paraphrase here.  There is a "pd_this" variable in
m_pd.c, pointing to the current Pd instance.  If this were made per-thread,
then it should be possible to run different instances on different threads
simultaneously; the only protection needed would be that each individual
instance should be protected by pdlib with its own lock.

(There would also have to be a global lock to protect pd_init(), which need
only be called as setup time).

But there's a snag, because the symbol table is global.  It wouldn't help to
make this per-thread, since calls to pd instances might migrate from thread to
thread.  Instead, we could do 1 of these 2 things:

1 (Peter's idea) : make gensym(), pd_bind(), and pd_unbind() threadsafe using
a lock.  Access via gensym() could be nonexclusive, as could locking out
pd_bind() and pd_unbind() during accesses to s->s_thing (we'd have to hunt
down everywhere in the code this is done).

I think there's a complication: what if you pass a message to an object via
a symbol's s_thing that's in a different instance from the current one
(pd_this) in the thread of the caller?  I don't know an easy way to determine
what pd instance an arbitrary object belongs to.


2. (another possibility): Go back and make the symbol table be per-instance. I
tried this earlier and got stumped because classes, which are global to all Pd
instances, contain a list of selectors (symbols) and their associated messages. 
If the symbol address changes because we switch to a new Pd instance, messages
(like #N print) no longer are associated with the method (print_new()), so
nothing works.

I think it's impractical to make classes per-instance, but what about making
each class maintain a separate list of messages for each Pd instance.  When
a new Pd instance is created, we'd go find all the classes, and add a new
message list to each of them for the new instance.

Then whenever one passes a message (assuming it's not one of s_bang, s_float,
s_symbol, s_list, or s_anything, which are usually handled by a faster
mechanism), the message passing functions pd_typedmess(), getfn(), etc., would
have to look up the message list associated with the current pd instance, and
then look down the list of selectors/methods as before.

Anyone see anything fatally wrong with this, and/or can option (1) be made
workable and is it better?


More information about the Pd-list mailing list