<div dir="ltr"><div>Thank, I understand much better ! It seems to me that can be good workaround. </div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font color="#000000"><span style="font-size:12.8px">1 (Peter's idea) : make gensym(), pd_bind(), and pd_unbind() threadsafe<br></span></font><font color="#000000"><span style="font-size:12.8px">using<br></span></font><font color="#000000"><span style="font-size:12.8px">a lock.  Access via gensym() could be nonexclusive, as could locking out<br></span></font><font color="#000000"><span style="font-size:12.8px">pd_bind() and pd_unbind() during accesses to s->s_thing (we'd have to hunt<br></span></font><font color="#000000"><span style="font-size:12.8px">down everywhere in the code this is done).</span></font></blockquote><div><br></div><div>One of the problems with this approach is the compatibility with external libraries. You can check and lock everywhere in the "vanilla" code when you access s_thing but you can't ensure that an external object does it. Ignoring external libraries can be a compromise but I think it's pretty restrictive. Or the drastic solution: make opaque the t_symbol and add new function "sendsym" that could lock the symbol and call "pd_typemess" if s_thing !=  NULL. This way, the future externals will be necessarily compatible but we won't be able to compile the new ones except if we update and correct the code...</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"><font color="#000000"></font><font color="#000000"><span style="font-size:12.8px">I think there's a complication: what if you pass a message to an object via<br></span></font><font color="#000000"><span style="font-size:12.8px">a symbol's s_thing that's in a different instance from the current one<br></span></font><font color="#000000"><span style="font-size:12.8px">(pd_this) in the thread of the caller?  I don't know an easy way to<br></span></font><font color="#000000"><span style="font-size:12.8px">determine<br></span></font><font color="#000000"><span style="font-size:12.8px">what pd instance an arbitrary object belongs to.</span></font></blockquote><div><br></div><div>If we assume that each instance has its own thread. Perhaps, when we bind an object to a symbol, the bindlist can "save" the current intance in the element (bindelem). Then when one of the method of the bindlist is called, it can check if the instance of the current thread is the same than the ones of the element.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="arial, helvetica, sans-serif" color="#000000">Anyone see anything fatally wrong with this, and/or can option (1) be made<br>workable and is it better?</font></blockquote><div><br></div><div>At first sight, the option 2 seems good.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There are many, many static local variable running around in Pd, some of<br>which may have to be referenced through pd_this</blockquote><div><br></div><div>Yes, indeed. In Camomile plugin, I encountered issues with sys_soundin, sys_soundout, sys_inchannels, sys_outchannels and sys_dacsr. I think it would be better if these variables were included to the pd instance (or thread local).</div><div><br></div><div>Cheers</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-02 17:40 GMT+01:00 Miller Puckette <span dir="ltr"><<a href="mailto:msp@ucsd.edu" target="_blank">msp@ucsd.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think I should have used what appears to be the standard term,<br>
"Thread-local storage" (<a href="https://en.wikipedia.org/wiki/Thread-local_storage" rel="noreferrer" target="_blank">https://en.wikipedia.org/<wbr>wiki/Thread-local_storage</a>).<br>
<br>
The idea is that, if you invoke pd_this from two threads simultaneously,<br>
they'll actually refer to two different memory locations and therefore<br>
won't interfere with each other.  This will be true as long as everything that<br>
is thread-unsafe is referenced through pd_this.<br>
<br>
There are many, many static local variable running around in Pd, some of<br>
which may have to be referenced through pd_this (while for others it may<br>
suffice to make them thread local themselves, which would mean they would<br>
be shared beween Pd instances that happened to use the same thread, and<br>
their values will change when a pd instance is migrated from one thread to<br>
another.  I think it will be necessary to look at each case individually.<br>
<br>
cheers<br>
<span class="gmail-HOEnZb"><font color="#888888">Miller<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Mon, Jan 02, 2017 at 02:36:36PM +0100, Pierre Guillot wrote:<br>
> That's a great news !<br>
> I don't understand what you mean by " If this were (pd_this) were made<br>
> per-thread". Perhaps that's the point I didn't understand when we were<br>
> speaking about it at the Pd convention. How can we ensure that an object, a<br>
> patch or whatever uses the right pd_instance ?<br>
><br>
> Here a concrete example of my problem, if you load a new patch (canvas) in<br>
> a specific instance, to ensure that the canvas is added to the canvas list<br>
> of this instance, you need:<br>
> 1 - Lock a global lock<br>
> 2 - Set the right instance<br>
> 3 - Load the patch<br>
> 4 - Unlock the global lock<br>
><br>
> I don't see how we can remove this global lock without changing the<br>
> functions' prototypes that use pd_this (by adding a instance's pointer as<br>
> argument and removing pd_this).<br>
><br>
><br>
> > 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<br>
> > 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<br>
> > to<br>
> > make this per-thread, since calls to pd instances might migrate from<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > per-instance. I<br>
> > tried this earlier and got stumped because classes, which are global to<br>
> > all Pd<br>
> > instances, contain a list of selectors (symbols) and their associated<br>
> > messages.<br>
> > If the symbol address changes because we switch to a new Pd instance,<br>
> > 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<br>
> > 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,<br>
> > 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.,<br>
> > would<br>
> > have to look up the message list associated with the current pd instance,<br>
> > 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>
> ><br>
</div></div></blockquote></div><br></div></div>