<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>That's a great news ! </div><div>I don't understand what you mean by " If this were (pd_this) were made per-thread". Perhaps that's the point I didn't understand when we were speaking about it at the Pd convention. How can we ensure that an object, a patch or whatever uses the right pd_instance ? </div><div><br></div><div>Here a concrete example of my problem, if you load a new patch (canvas) in a specific instance, to ensure that the canvas is added to the canvas list of this instance, you need:</div><div>1 - Lock a global lock  </div><div>2 - Set the right instance</div><div>3 - Load the patch</div><div>4 - Unlock the global lock</div><div><br></div><div>I don't see how we can remove this global lock without changing the functions' prototypes that use pd_this (by adding a instance's pointer as argument and removing pd_this).  </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Sun, 1 Jan 2017 15:31:51 -0800<br>
From: Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>><br>
To: <a href="mailto:pd-list@iem.at">pd-list@iem.at</a><br>
Subject: [PD] threadsafe multi-instance Pd?<br>
Message-ID: <20170101233151.GE21861@fuzz.<wbr>localdomain><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
To Pd List,<br>
<br>
Here's my promised followup mail on Pd thread-ability (the hoped for<br>
ability to call Pd instances, via pdlib, from separate threads concurrently).<br>
<br>
Peter Brinkmann made a suggestion during the Pd convention round-table<br>
discussion that I'll paraphrase here.  There is a "pd_this" variable in<br>
m_pd.c, pointing to the current Pd instance.  If this were made per-thread,<br>
then it should be possible to run different instances on different threads<br>
simultaneously; the only protection needed would be that each individual<br>
instance should be protected by pdlib with its own lock.<br>
<br>
(There would also have to be a global lock to protect pd_init(), which need<br>
only be called as setup time).<br>
<br>
But there's a snag, because the symbol table is global.  It wouldn't help to<br>
make this per-thread, since calls to pd instances might migrate from thread to<br>
thread.  Instead, we could do 1 of these 2 things:<br>
<br>
1 (Peter's idea) : make gensym(), pd_bind(), and pd_unbind() threadsafe using<br>
a lock.  Access via gensym() could be nonexclusive, as could locking out<br>
pd_bind() and pd_unbind() during accesses to s->s_thing (we'd have to hunt<br>
down everywhere in the code this is done).<br>
<br>
I think there's a complication: what if you pass a message to an object via<br>
a symbol's s_thing that's in a different instance from the current one<br>
(pd_this) in the thread of the caller?  I don't know an easy way to determine<br>
what pd instance an arbitrary object belongs to.<br>
<br>
OR:<br>
<br>
2. (another possibility): Go back and make the symbol table be per-instance. I<br>
tried this earlier and got stumped because classes, which are global to all Pd<br>
instances, contain a list of selectors (symbols) and their associated messages.<br>
If the symbol address changes because we switch to a new Pd instance, messages<br>
(like #N print) no longer are associated with the method (print_new()), so<br>
nothing works.<br>
<br>
I think it's impractical to make classes per-instance, but what about making<br>
each class maintain a separate list of messages for each Pd instance.  When<br>
a new Pd instance is created, we'd go find all the classes, and add a new<br>
message list to each of them for the new instance.<br>
<br>
Then whenever one passes a message (assuming it's not one of s_bang, s_float,<br>
s_symbol, s_list, or s_anything, which are usually handled by a faster<br>
mechanism), the message passing functions pd_typedmess(), getfn(), etc., would<br>
have to look up the message list associated with the current pd instance, and<br>
then look down the list of selectors/methods as before.<br>
<br>
Anyone see anything fatally wrong with this, and/or can option (1) be made<br>
workable and is it better?<br>
<br>
cheers<br>
Miller<br>
</blockquote></div><br></div></div>