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.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:
- 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)
- 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@vt.edu http://www.music.vt.edu/faculty/bukvic/