<div dir="ltr">Sorry for the delay.<br>#1 I agree. Seems like a workaround. Ultimately it should be clear in the source code when a static is meant to be shared across threads or not.<br> Seems like something that could be properly implemented in the future?<br>
<br>#2 Sounds good, but Im not familiar with which variables are symbol table related, DSP chain related, etc.<br> Im of the mind, Id just like to put them *all* into one structure, to get a stable release, and then individual variables can be pulled back out in future as the need arises.<br>
Id be inclined to throw everything into one structure, and name things according to which file they originated in:<br><br>example, firstnet in d_fftroutine.c would live as an entry<br><br>struct PDinstance {<br> ...<br>
FFT_NET *d_fftroutine_firstnet;<br> ...<br>} <br><br>This would allow one to at least see where the variable is used.<br><br> #3 Peter mentions that in order to support legacy code, all API calls would need to be mirrored, with and without the pd-instance variable.<br>
I don't think C allows for overloading, so would this require a separate name for all the functions?<br>Would supporting two parallel APIs be wanted though, or just lead to confusion?<br>Is this in order to support previously compiled objects (Dlls)?<br>
<br>-Rob<br><br><br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 5:30 AM, Kjetil Matheussen <span dir="ltr"><<a href="mailto:k.s.matheussen@gmail.com" target="_blank">k.s.matheussen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Miller,<br>
<br>
Idea #1 sounds quite good, except that it sounds hacky<br>
and that performance might go down notifiable because<br>
of thread switching. The extra amount of code necessary<br>
to switch threads doesn't sound like too much work.<br>
<br>
So I like idea #2 much better. The limitation of only one<br>
DSP chain was the only good reason for implementing<br>
multiple pd instances for Radium. If you implement #2,<br>
that's probably good enough for Radium, and most likely<br>
good enough for most others too. At least, it's a very<br>
good start.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Sun, Dec 8, 2013 at 6:53 PM, Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>> wrote:<br>
> Hi all -<br>
><br>
> two idea, neither of them as general but perhaps much easier to pull off:<br>
><br>
> 1. make macros like:<br>
> #define STATIC static __thread<br>
><br>
> and rely on gcc's per-thread static storage mechanism. This would involve<br>
> some global search-and-replace action but wouldn't clutter the code too badly.<br>
> The downside is it would require that each instance of libpd would have to<br>
> run in its own thread - As Peter pointed out to me, in many situations the<br>
> programmer can't even determine at compile time whether this would be true<br>
> or not.<br>
><br>
> I'm not sure but I think other C compilers besides gcc might support __thread<br>
> these days.<br>
><br>
> 2. Just make the symbol table and DSP chain per-instance, and leave the rest<br>
> alone. This only solves a subset of the problem (things like the search path<br>
> would remain global) but my intuition has it that fixing these two would be<br>
> enough so that people could practically make patches that don't interfere<br>
> with each other. (Making the symbol table per-instance would keep things<br>
> like arrays, send/receives, etc., from cross-talking.)<br>
><br>
> The result wouldn't be thread-safe; however, combining this with the<br>
> __thread idea from above would probably work, and then you'd have something<br>
> that would at least work (although perhaps slightly differently) in<br>
> same-thread and multi-thread contexts.<br>
><br>
> These are just ideas - if there's enough interest I can pull (2) off quite<br>
> easily; (1) would be a global search-and-replace mess that would likely<br>
> conflict with every source-code patch out there (e.g., all the patches that<br>
> are applied for Pd extended) so I'd need a real good reason to inflict that<br>
> one on the world.<br>
><br>
> cheers<br>
> Miller<br>
><br>
> On Sun, Dec 08, 2013 at 10:12:03AM +0100, Kjetil Matheussen wrote:<br>
>> Excellent plan.<br>
>><br>
>> In my branch of libpd on Github, I've solved the Pd multiple<br>
>> instances problem by letting the linker take care of separating<br>
>> the global variables. However, using the linker causing various<br>
>> problems, such as making it very difficult to load externals,<br>
>> and it should probably also be considered a hack.<br>
>> Your plan (the plan I didn't bother doing in my branch) is quite<br>
>> undoubtedly the proper way to do it, and hopefully I would have time to<br>
>> help. At least I would be helping to debug it afterwards,<br>
>> because I would start using this system (in the Radium music editor),<br>
>> instead of my own, to embed Pd instances.<br>
>><br>
>> And an advantage to Pd itself might be that the source could be clearer when<br>
>> variables that belongs to the instance, actually are denoted as such<br>
>> in the text.<br>
>><br>
>> There is also quite microscopic concern, which is that the added<br>
>> amount of text could make the source more difficult to read,<br>
>> here and there. Maybe a very short variable name for the pd instance,<br>
>> such as "p", "pi', would be a good idea. (i.e. not "pure_data_instance").<br>
>><br>
>><br>
>><br>
>> On Sat, Dec 7, 2013 at 10:20 PM, Rob Bairos <<a href="mailto:rob@derivative.ca">rob@derivative.ca</a>> wrote:<br>
>> > Sorry, most of my original post got cut off.<br>
>> > Here's the rest (minus the list of symbols) in case its causing a problem:<br>
>> ><br>
>> ><br>
>> > From my understanding, the current proposed solution is to take all statics<br>
>> > and globals,<br>
>> > encapsulate them in one object, and pass that object to all api calls.<br>
>> > Peter further suggested legacy api is maintained by having them call the new<br>
>> > api with a default instance object.<br>
>> ><br>
>> > I did a little bit of hunting, using objdump on the current dll, to get a<br>
>> > rough list of all the globals and statics currently involved.<br>
>> ><br>
>> > Im thinking the *_class and *_sym static pointers are in fact constant, and<br>
>> > need only one shared instance. That would leave about 320 variables<br>
>> > remaining.<br>
>> > Many of these variables are constant arrays, strings, etc.<br>
>> > And many seem to be used only as a shortcut for passing data between two<br>
>> > functions, possibly bringing down the number further.<br>
>> ><br>
>> > Im toying with the idea of taking on this task if anyone's interested.<br>
>> > I may require some tips and help from the forum, in terms of creating a<br>
>> > branch, explanation of some statics etc.<br>
>> ><br>
>> > So how feasible is this? Am I on the right track?<br>
>> > Thanks very much,<br>
>> > Rob Bairos.<br>
>> ><br>
>> > _______________________________________________<br>
>> > Pd-dev mailing list<br>
>> > <a href="mailto:Pd-dev@iem.at">Pd-dev@iem.at</a><br>
>> > <a href="http://lists.puredata.info/listinfo/pd-dev" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> Pd-dev mailing list<br>
>> <a href="mailto:Pd-dev@iem.at">Pd-dev@iem.at</a><br>
>> <a href="http://lists.puredata.info/listinfo/pd-dev" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br>
</div></div></blockquote></div><br></div>