[PD-dev] per-thread storage in Pd in support of pdlib - discussion?
reakinator at gmail.com
Tue Jan 31 05:07:35 CET 2012
I'm really happy to see this conversation.
On Fri, Jan 27, 2012 at 7:45 AM, Charles Henry <czhenry at gmail.com> wrote:
> On Wed, Jan 25, 2012 at 5:32 PM, Peter Brinkmann
> <peter.brinkmann at googlemail.com> wrote:
> > I don't think users have anything to gain from fine-grained control of
> > threads. That seems like an optimization hint that may or may not be
> > helpful, depending on a lot of factors that are not obvious and will
> > from machine to machine. In any case, I don't want to have to think
> > threads when patching any more than I want to think about, say, NEON
> > optimizations.
> I'm still making the case here:
> Suppose you're writing a patch and you run up against the limitations
> of a single-threaded process. Then, you take some portion in a
> sub-patch and drop in a "thread~" object. You're able to selectively
> add the functionality where it matters to you *and* only when you
> actually need it.
Isn't this problem addressed with the [pd~] object? It runs it's patches
in it's own process instead of thread and I'm not sure why, but it will do
what your describing, no?
> The generalizable case is much more preferrable, I agree, but as you
> say further on, you might develop an application that incurs
> significant overhead--and may not be appropriate for all applications.
I see the next important step as making the general cases easier to handle.
A per-thread context such as IOhannes and Peter describe above seems like
the best approach to allowing a program to run multiple instances of pd in
a much more predictable manner, while it still allows for backwards
compatibility (via a default 'legacy' context). I see parallel processing
as a different topic, although it will be easier to implement once the
static variables are taken care of.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-dev