I'm not sure whether dynamic class loading is thread-safe - it won't cause crashes (I think) because class_new(), etc., have a global lock. There would in the end be two "classes" one of which would alias the other's name. But there might be unwanted side effects here that I haven't smoothed out yet.
In working on libpd today I've noticed two other thread-unsafe situations: dollar zero and search path manipulations, which I need to make per-Pd-instance.
as to (2)... I believe legacy externals will have to be recompiled if they use symbols like "s_float" - or, later, whatever other static external variables I end up making per-instance. In this case they'll fail to load into multi-instance environments. (They'll still load into Pd vanilla since I compile that with PDINSTANCE undefined). So I believe we'll have binary compatibilty for Pd vanilla, and for most externs when loaded into libpd, but some others will refuse to load and have to be massaged as in
&s_float ..> gensym("float")
But who knows what other horrible problems will come up. I don't expect this to be an easy process... but I think it will be worth it in the end...
cheers Miller
On Mon, Apr 17, 2017 at 06:32:31PM +0000, Jonathan Wilkes wrote:
- If thread #1 loads [foo] from foo.pd_linux, and thread #2 loads [foo] from foo.pd_linux, what happens?
- Will there be any public interfaces external developers can use to keep from making their own ad-hoc, buggy revisions to legacy externals?
-Jonathan