[PD] close all patches on quit sourceforge patch

[Ivica Bukvic]

It is only the draw command, not the communication...

BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all gui
requests?
On Oct 24, 2012 8:32 PM, "Hans-Christoph Steiner" <hans at at.or.at> wrote:

>
> Thanks for that info.  Sounds like a good idea in general.  I personally
> can't
> think of any reason why the DSP would need to be on during the quitting.
>  But
> for the 'redraw' part, that depends.  If it is literally only redrawing
> that
> is suspended, that would be fine.  But if its all Pd<-->GUI communications,
> that will probably cause problems.
>
> .hc
>
> On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
> > Hans and Iohannes,
> >
> > The following is FYI.
> >
> > Several months ago I integrated the close all patches before quitting
> patch
> > in pd-l2ork and since then I've been experiencing extremely sporadic
> crashes
> > on close that would hang pd-l2ork. Now, I am not sure this is because of
> > architectural differences between regular pd and pd-l2ork but I doubt it
> > since most of the said components are very similar if not identical.
> >
> > The bottom line is this only occurs on very low-powered machines (e.g.
> > netbook) and relatively large patches and even then it does so very
> > sporadically. Consequently, I implemented an improvement to the closing
> > mechanism that consists of 2 additional steps and apparently alleviates
> said
> > problems entirely:
> >
> > 1) disable further redraws (this prevents calling functions that may be
> > referencing null pointers)--I have a special global var for this which is
> > also being used to optimize redrawing (many actions in pd-l2ork are
> several
> > times faster than regular pd as a result of this implementation--just
> look
> > for do_not_redraw call in the source if curious)
> >
> > 2) suspend dsp before going through the patches (all sub-patches try to
> > suspend it and resume it but for some reason, due to asynchronous nature
> of
> > communication between tcl and c funny things occasionally happen on
> > low-powered machines, so this way we ensure it is entirely off throughout
> > the whole destruction process)
> >
> > Hope this helps!
> >
> > Ivica Ico Bukvic, D.M.A.
> > Composition, Music Technology
> > Director, DISIS Interactive Sound & Intermedia Studio
> > Director, L2Ork Linux Laptop Orchestra
> > Head, ICAT IMPACT Studio
> > Virginia Tech
> > Dept. of Music - 0240
> > Blacksburg, VA 24061
> > (540) 231-6139
> > (540) 231-5034 (fax)
> > ico at vt.edu
> > http://www.music.vt.edu/faculty/bukvic/
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121024/bd7f6de9/attachment.htm>