[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

[Rich E]

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
> differ
> > from machine to machine.  In any case, I don't want to have to think
> about
> > 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...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120131/2ad7f40e/attachment.htm>