[PD-dev] libpd partly working with pd instances

[IOhannes m zmölnig]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20140517/5765290b/attachment-0002.sig>