[PD] close all patches on quit sourceforge patch

Hans-Christoph Steiner hans at at.or.at
Thu Oct 25 03:02:33 CEST 2012


Stack overflow usually comes from recursiveness in patches until Pd's stack
overflows, or at least that's my experience of that error.

The pdtk_post logic has changed a lot in 0.43 with drastic improvements.  You
can now post 1000 lines/sec and still patch in Pd.

In related work, I've been playing around with making array redrawing respect
the Tk event loop more.  Basically, each draw command you send gets queued
until the event loop executes it.  But for something like an array, there is
no reason to draw multiple times in a single loop, so when a new draw command
gets posted, it cancels the previous one if it hasn't run already.  That is
the key to what made pdtk_post so much faster as well.  Another part of that
is using "after idle" so that Tk doesn't drop everything to try to run that
command, but instead queues it to happen in a big chunk.

You can see the first stab at this work for arrays in the attached patches.
The first patch is only there because it needs to be applied for the 2nd patch
to apply cleanly.  They apply to pure-data.git master.

.hc


On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
> 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/
>>>
>>>
>>>
>>
> 


More information about the Pd-list mailing list