Howdy all, form my side, I can't really add anything here. I have not dug into these kinds of lower level aspects of Pd. My knowledge extends really to just what is needed to main / update / extend and ultimately use Peter's original work. The pd_instances and pd_ninstances and the instance framework in the core was added by Miller and the Pd dev community wrapped it. I formalized the experiments into the instance api that is in libpd right now. I don't claim that is the best, just that I was able to make work without hopefully breaking too many existing projects (including my own). 😀
> On Jul 1, 2026, at 8:14 PM, Christof Ressi <[email protected]> wrote: > > Sorry, late to the party. > >> the two things to take care of that I know of are: >> - using data that is static (or otherwise shared between threads) obviously >> needs special handling. >> - the convenience static variables exported by Pd ("s_float" and friends) >> should be replaced with explicitly generated symbols (gensym(...)) > For most externals, this is pretty much it. Regarding global data that is > only valid for a particular instance, I would like to call attention to > https://github.com/pure-data/pure-data/pull/2780. > > There are some edge cases with externals that use worker threads. In a > multi-instance Pd, the worker thread must explicitly set the Pd instance so > that it can call API functions (that do not take the instance as an argument). > > I have seen externals that use sys_lock() and sys_unlock() to temporarily > lock Pd and then call API functions. This is actually dangerous because it > can lead to deadlocks, but this wasn't documented until recently. > > I have added pd_queue_mess() as a safe alternative in Pd 0.56. This function > takes the Pd instance as a first argument, so it does not require a call to > pd_setinstance() and thus works the same in single-instance and > multi-instance Pd. > > There might still be cases where worker threads require a call to > pd_setinstance(). For example, once pd_post() and friends become thread-safe, > people would want to use them in worker threads. For that purpose, it might > make sense to provide pd_setinstance() and pd_getinstance() unconditionally. > > Christof > > > On 6/29/2026 1:15 PM, IOhannes m zmoelnig via Pd-dev wrote: >> i don't really use libpd (and i am too lazy to read the code now - it's >> almost 40°C here...), so I thought I'd ask here: >> >> can I just build externals that are usable by both ordinary Pd-vanilla and a >> (lib)Pd that has been compiled for multi-instance (PDINSTANCE) and/or >> multi-threading (PDTHREADS)? >> >> and vice-versa: when I build an external with PDINSTANCE/PDTHREADS, can I >> use it in ordinary (single-instance, single-threaded) Pd? >> >> my first tests (building a pseudo-Pd (based on libpd) that has both >> PDINSTANCE & PDTHREADS enabled), shows that this shouldn't actually pose a >> problem (i tried running the few test-suites I have (zexy & iemmatrix), and >> that went fine. i didn't actually test with two instances (threaded or not), >> which would expose a whole new set of problems :-) >> >> the two things to take care of that I know of are: >> - using data that is static (or otherwise shared between threads) obviously >> needs special handling. >> - the convenience static variables exported by Pd ("s_float" and friends) >> should be replaced with explicitly generated symbols (gensym(...)) >> >> the latter is only needed, when trying to run a non-PDINSTANCE external in a >> PDINSTANCE host (or vice-versa). >> >> anything else I am missing? >> >> >> i am thinking of distributing externals that are build with both PDINSTANCE >> & PDTHREADS, in order to make the usable for not-just-Pd-vanilla. >> >> gfasmdr >> IOhannes >> >> >> >> --- >> [email protected] - the Pd developers' mailinglist >> https://lists.iem.at/hyperkitty/list/[email protected]/message/524G7R7WI5QKPS3TQEGY3YMM5K3N64RU/ > > --- > [email protected] <mailto:[email protected]> - the Pd developers' > mailinglist > https://lists.iem.at/hyperkitty/list/[email protected]/message/ZL3ACYCIPFE2NVQBFMW54P7SQ4WPAEXW/ -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
--- [email protected] - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/S77ZRKQKQDKQEA6RNYZMSGPTOCLAUQNO/
