Re: [PD-dev] Multiple Instance of pdlib
On Wed, Dec 11, 2013 at 8:52 AM, Kjetil Matheussen wrote: > On Wed, Dec 11, 2013 at 3:55 AM, Miller Puckette wrote: >> >> I'm liking the idea of simply "localizing" symbols and the DSP chain more >> and more as I think about it... it's nice and self-contained and I think it >> would help things a lot from what I'm hearing. >> > > Perhaps I misunderstand what you talk about, but for Radium, > I think a shared symbol table could be better. > Then you can share arrays and other things between instances. > (And patch specific symbol names should be injected with $0 anyway.) Oh, but for sending messages between instances, you would have to queue the messages, and then it starts to get complicated... ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Multiple Instance of pdlib
On Wed, Dec 11, 2013 at 3:55 AM, Miller Puckette wrote: > > I'm liking the idea of simply "localizing" symbols and the DSP chain more > and more as I think about it... it's nice and self-contained and I think it > would help things a lot from what I'm hearing. > Perhaps I misunderstand what you talk about, but for Radium, I think a shared symbol table could be better. Then you can share arrays and other things between instances. (And patch specific symbol names should be injected with $0 anyway.) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Multiple Instance of pdlib
Well, I think "#1" (making statics per-thread) is only necessary on the
assumtion that you want Pd running simultaneously in multiple threads;
otherwise it would accomplish nothing. I'm not sure but I guess the overhead
would be the same as the "one-structure" solution (which is essentially how,
I think, the per-thread thing would have to work internally anyhow.)
The idea of throwing all statis/externs into a data structure wouldn't
extend to externs, which would be ugly since it would mean the API for
internal objects would have to be different than for externs (which would
have to make their own data structures, per-Pd-instance, and would have to
have some way to look those up from the Pd instance. Also, the idea of
having a data structure that you have to change to add anthing static to
anything at all inside Pd sounds quite heavy to me.
I'm liking the idea of simply "localizing" symbols and the DSP chain more
and more as I think about it... it's nice and self-contained and I think it
would help things a lot from what I'm hearing.
cheers
Miller
On Tue, Dec 10, 2013 at 01:07:08PM -0500, Rob Bairos wrote:
> 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
> wrote:
>
> > 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 wrote:
> > > Hi all -
> > >
> > > two idea, neither of them as general but perhaps much easier to pull off:
> > >
> > > 1. 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.
> > >
> > > 2. 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
>
Re: [PD-dev] Multiple Instance of pdlib
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
wrote:
> 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 wrote:
> > Hi all -
> >
> > two idea, neither of them as general but perhaps much easier to pull off:
> >
> > 1. 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.
> >
> > 2. 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 a
