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

[Charles Henry]

On Sat, Jan 14, 2012 at 3:04 PM, Miller Puckette <msp at ucsd.edu> wrote:
> To Pd dev -
>
> For some time the good folks who brought us pdlib have been asking how
> one could make it possible to run several instances of Pd in a single
> address space.

Maybe I have on my audio-colored glasses--but that's just where I see
things happening.

I remember a conversation with IOhannes in August about
multi-threading audio via sub-canvas user interface object (propose
thread~ akin to block~).  If all you're after is audio
multi-threading--there's no need for multiple instances of Pd.
Threads could be used to start a portion of the dsp chain, running
asynchronously, and then join/synchronize with Pd when finished.

What this would look like:  Add a thread_prolog, thread_epilog, and
thread_sync function. The thread_prolog function that occurs before
block_prolog, starts a thread running the portion of dsp chain
cointained within, and returns the pointer to the function following
the thread_epilog.  The thread_epilog function that occurs after
block_epilog--waits for synchronization and returns.

What's the difficult part: You would need to have a good ordering of
the dsp chain to take advantage of concurrency--each subcanvas having
a thread~ object needs to kick off as early as possible, followed by
objects that have no dependence on its output.  Secondly, you'd need
to put thread_sync on the dsp chain immediately before you will
encounter functions with data dependencies.

What this approach would provide: a user interface to control audio
threading, without having any duplication of global
variables/arrays/symbols, etc.  It would put the threading operations
closer to the calculations to be performed, and so eliminate many
problems as being out-of-scope.

I've been looking at asynchronous dsp chain operations for my PdCUDA
project (which is several months behind where I expected to be)--the
basic problem is the same.  I haven't gotten that far yet, but someday
I'm going to get to the point where improvements will be made by
changing the order in which perform functions are placed on the dsp
chain.

Maybe this doesn't fit what you want--so I'd refer back to problem
definition.  What's the point of threading and the usage case you have
in mind?

Chuck