Yep, I don't think there's any way to make Pd callable from multiple threads except by making pd_this either an argument to every Pd function call (thus completely changing the API) or by making pd_this per-thread. But doing the latter by no means restricts a one-thread-per-instance or a one-instance-per- thread model.
My idea is this: Pd instances can migrate from thread to thread at the caller's will, but no two threads can refer to the same Pd instance at the same time. This is realized by having each thread have its own current instance, which the caller may set at will (from any thread). Each instance has a lock to prevent any thread from setting pd_this to an instance another thread already has set.
I think I need to find a way to detect at configuration time (?) whether the compiler supports per-thread storage, hmm....
cheers Miller
On Wed, May 03, 2017 at 01:55:31PM +0200, IOhannes m zmoelnig wrote:
On 2017-04-17 22:03, Miller Puckette wrote:
Meanwhile, there's no assumed relationship between instances and threads.
i was tempted to say hooray, but then...
... i discovered the use of the PERTHREAD macro which expands to "__thread" which is the keyword for TLS (thread local storage); i don't really see how this relates to "no assumed relationship between instances and threads". (though i have to admit that i haven't fully studied the code yet).
in any case, what's probably more important: it seems that at least some of the compilers shipped with OSX do not support thread-local storage at all [1].
this shows in the travis-ci builds, which currently fail for OSX: https://travis-ci.org/pure-data/pure-data/jobs/227985898
fgas,dr IOhannes
[1] e.g. https://bugs.freedesktop.org/show_bug.cgi?id=98603 this thread also suggests, that there might be workarounds if one could raise the "osx-minversion" to >=10.7
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev