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

Peter Brinkmann peter.brinkmann at googlemail.com
Tue Jan 31 06:44:09 CET 2012

> 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.

Actually, I would sum up the thread slightly differently.  We've touched
three different topics: support for multiple instances of Pd, a potential
refactoring of Pd on top of a library like libpd, and support for
concurrency.   As I see it, those three issues are largely orthogonal to
one another.  In particular, I'd rather not entangle multiple instances
with multiple threads.

As far as libpd is concerned, the most important part is to achieve support
for multiple instances.  Tying instances to threads wouldn't be too helpful
because there are lots of legitimate use cases where one thread needs
multiple instances, as well as use cases where one instance is shared
between threads.

The next step would be a refactoring of Pd, towards a more portable user
interface.  There's been an ongoing thread at Pd Everywhere on porting the
UI to mobile devices (
and  I wrote up a few thoughts on my blog (

Support for concurrency comes in third on my list.  I already outlined most
of my concerns in previous messages, and I also figure that this should be
tabled until the other two problems have been solved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120131/b52dbf49/attachment-0001.htm>

More information about the Pd-dev mailing list