[PD] puredata evolution

[Mathieu Bouchard]

On Thu, 31 May 2007, Miller Puckette wrote:

> The great majority of DSP objects are side-effect-free and thread-safe.

On average it doesn't matter, because video is the high-bandwidth, 
high-crunching task, while audio is becoming (or already is) 
low-bandwidth, low-crunching, in comparison to the machine's capacity, 
even without using SIMD. There still isn't any pd DSP subsystem that 
carries video (there was one in jMax...).

> what's more, I don't think there's any reliable way to determine that an 
> object is threadsafe.

A reliable way to determine is to look up a table that lists all the 
object classes that are known to be threadsafe. That's at least as 
reliable as the humans that certify the threadsafeness.

> So a parallelized version of Pd would, in practice, occasionally crash 
> mysteriously.

Only if there are object classes in that list, that shouldn't be there.

> Furthermore, as new DSP objects get written new sources of crashes would 
> appear, leaving us in all liklihood in a situation where no version of 
> Pd ever emerged that was entirely free of thread-related crashes.  Not a 
> real pretty sight.

If there are any crashes that you can't debug, you can still reduce the 
amount of threadliness.

Almost all race-conditions in pd would result in wrong output instead of 
crashes. If you want to address threading issues, consider all 
race-conditions, not just crashes.

> Another possibility would be to make Pd open up several address spaces and
> run portions of the patch in then.  This was how Max/FTS worked on the ISPW.

With or without shared memory?

> Just to offer my two cents...

USA's currency is falling down nowadays.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada