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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
