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