[PD-dev] defining PDINSTANCE and PDTHREADS in libpd
msp at ucsd.edu
Wed May 3 16:24:33 CEST 2017
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-
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....
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 .
> this shows in the travis-ci builds, which currently fail for OSX:
>  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 at lists.iem.at
More information about the Pd-dev