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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
