#559 Improving PD for multi-instances and multithreading

[Pierre]

2 things that could really improve the development of applications with Pure Data :

1 - "t_pdinstance" in the prototypes of the functions "sched_tick()" and "dsp_tick()". This way, we don't need to call "pd_setinstance" at each dsp tick so it is thread safe.
(we could have something like "pdinstance_sched_tick(t_pdinstance x)" and "pdinstance_dsp_tick(t_pdinstance* x)" to ensure the good working of previous applications)

2 - "t_pdinstance" in the structure of the clock. All the clock_new functions seem to be called in the "creation" methods of the objects. If when we load a patch and we create objects, "pd_this" is well defined, we can initialize the reference "t_pdinstance" of the clock with "pd_this" and later when we'll call "clock_set" (for example) the clock will use its reference instead of "pd_this". In this case, imagine that we send a bang to a [delay] in one instance during the loading of a pacth in another instance, even if "pd_this" is not the good one, the clock will be added to the clocks list of its instance.

My first mail :
http://lists.puredata.info/pipermail/pd-dev/2015-09/020339.html

[Miller Puckette]

I'm not sure but I don't think these would really make Pd thread-safe - instead, they would merely reduce the frequency of thread crashes. For one thing, there are indeed built-in objects (pipe, makenote) and perhaps externs that use clock_new outside of patch loading time. Anyway, anytime someone calls gensym() at run time (which happens frequently) there's no thread safety. This will cause occasional, very hard to reproduce crashes.

The only real solution I know of would be to use thread-local storage for all static variables; this would require replacing "static" with a macro ("PDSTATIC" perhaps) that could be expanded to "static __thread" (or whatever cc eventualy standardizes on).

[Miller Puckette]

Closing this - recent work makes it unnecessary (I think).