[PD] threads in pd, dataflow

Jonathan Wilkes jancsika at yahoo.com
Sat Feb 22 22:16:31 CET 2014


On 02/21/2014 10:04 PM, Simon Wise wrote:
> On 22/02/14 06:28, Jonathan Wilkes wrote:
>> On 02/21/2014 06:41 AM, Simon Wise wrote:
>
>>> Something to really make pd parallel would involve treating fan-outs as
>>> opportunities for the interpreter to launch each branch in a new 
>>> thread,
>>> implementing the inherent parallelism in the dataflow paradigm (e.g. in
>>> the pd definition of fan-outs as being executed in undefined order). 
>>> Here
>>> the trigger object is used to force sequential execution where 
>>> required,
>>> just as it is now.
>>
>> Practically speaking, it's completely different for control than for 
>> signal
>> domain. For signal domain fanouts there's an understanding that Pd gets
>> stuff done when it needs to get done. In the control domain, there's 
>> even a
>> philosophy of _never_ having fanouts at all. I don't know what the 
>> effect
>> would be of trying to auto-parallellize a signal diagram, but I'm pretty
>> sure trying to auto-parallellize a control diagram wouldn't make much 
>> of a
>> dent.
>
> I was referring to parallelising using control fanouts only, but 
> didn't make that clear. 'No fanouts, always use triggers' is a very 
> sensible policy to avoid easily overlooked bugs when, as in pd, 
> fanouts are just an implied trigger with an undefined order.
>

[...]

> Even the dsp<->gui problem would be addressed by a proper dataflow 
> implementation if it was done well. Keeping all the gui stuff in 
> branches which don't have ~ objects should result in these branches 
> being separate threads, and well implemented these would not be 
> allowed to block ~ branches.

To know whether a control branch interacts with the signal domain is to 
solve the halting problem, no?

But you could have some kind of "seal" object that verifies the user 
thinks a subpatch or canvas is 100% pure control domain.  And then Pd 
could take that to mean throw it in its own thread (and throw 
warnings/errors if it finds a message going to a signal object, or 
fudging with dsp in any way).

It could look like a wax seal and always be at the top-left of the patch.

-Jonathan



More information about the Pd-list mailing list