On 05/16/2014 07:34 AM, Miller Puckette wrote:
I think that would work (if Pd was compiled with the "thread lock" enabled) but the two wouldn't be able to run simultaneously;
the problem is, that if someone made Pd into a (e.g.) VST-plugin (and judging from the responses to your announcement mail, a lot of people definitely would like that to happen), then you cannot make any assumptions about how the host will deal with multiple instances of that plugin. the host may choose to run all it's plugins in parallel :-(
efficiency and might make it harder to get low real-time latencies out of a two-sound-card system.
but this is something the application devs have to worry about, not necessarily Pd.
I'm always nervous about multi-threaded real-time systems on the whole (they can be prone to occasional crashes that are hard to re-create). But if there's demand for it I could go ahead and make static storage in PD per-thread which would theoretically make Pd thread-safe. That would work unless for some reason it happened to crash mysteriously and un-debuggably.
but wouldn't this totally break all threaded objects? e.g. [readsf~]'s file-access thread would see different thread-local variables. you probably can fix [readsf~], but what about externals? e.g. readanysf & Gem use threads quite a bit, flext has thread support,...
i really think that making Pd re-entrant by bundling all static variables in a single per-instance struct is the way to go.
fgmasrd IOhannes