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