[PD-dev] Improving PD for multi-instances and multithreading.

[Pierre Guillot]

Hi Miller,
You're right, for these objects the method will fail. One solution would be
to offer another clock_new function with t_pdinstance as third argument but
perhaps the solution goes too far and there are certainly others devs that
create clocks on the fly.

Another (stupid?) proposition :
Perhaps it would be possible to extend the size of the objects in the
pd_new function , for example :
*x = (t_pd *)t_getbytes(c->c_size + sizeof(t_pdinstance *);*
to save the instance in the structure of the object :
*t_pdinstance *pt = (t_pdinstance *)((char *)x)+c->c_size;*
*pt = pd_this;*
and then we will be able to safely use some methods by retrieving this
pd_instance on the fly.

I know this is not really a solution, but a start for thinking about a
thread safe version of Pure Data. If it is one of your concern, I'll be
pleased to discuss about it. Anyway my plugin works very well so I'm
certainly going too far... but it must be my geek side.

Cheers

2015-09-10 17:54 GMT+02:00 Miller Puckette <msp at ucsd.edu>:

> HI Pierre -
>
> Maybe I'm missing something but I don't think this would work.  Objects
> like
> pipe and makenote call clock_new on teh fly (and I can't see how to get
> pd_this
> to them safely).
>
> cheers
> Miller
>
> On Thu, Sep 10, 2015 at 11:22:47AM +0200, Pierre Guillot wrote:
> > Since few weeks, I work on a plugin that dynamically loads Pure Data
> > patches, creates a GUI depending on the graphical objects of the patch
> and
> > retrieves their parameters to link them with the automation system of the
> > host. Everything works fine, but I had some issues to manage several PD
> > instances with multiple threads (pdlib doesn't manage multiple
> instances).
> >
> > I made my own implementation that solved the problem and I found 2 small
> > things that could really improve the development of applications with
> Pure
> > Data.
> >
> > I try to explain :
> > The main problem isn't the loading of patches that can be managed using
> > locks but  running the pacthes in parallele. For what I've seen, attack
> > ships on fire off the shoulder of Orion... sorry I digress. For what I've
> > seen, there are only 2 things that cause problems : the dsp chains and
> the
> > clocks. Here my solutions :
> >
> > 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" 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.
> >
> > For the moment, I don't use this updates (I manage everything with locks)
> > because I want to be compatible with future versions of Pure Data. But if
> > you think that can be a good thing, I can submit the code. Can I use
> GitHub
> > for this ?
> >
> > Cheers
>
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at lists.iem.at
> > http://lists.puredata.info/listinfo/pd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150910/f12b30e1/attachment-0001.html>