[PD] What exactly is a "stack overflow" ?
Mathieu Bouchard
matju at artengine.ca
Thu Dec 20 22:14:43 CET 2007
On Thu, 20 Dec 2007, Russell Bryant wrote:
> Well, now that i think of it, I think this change is a bit unreasonable. So, I
> take it back. :) It introduces a small performance hit
No, this one is most likely a *big* performance hit.
> even if you screw up, it _will_ stop eventually, after some 4 billion
> something iterations. How long it takes is completely dependent on what
> you have after the [until].
This is still way too much, but it's too complicated to get pd to support
interrupting its own calculations unless all externals are compiled with
C++ exception support, and even then, it's tricky because you can't
directly add exception support to libc itself or whatever else.
If one can't wait, it's possible to restart pd without losing any changes.
In DesireData, all changes made to patches are backed up in the Tcl/Tk
process, so unless both processes crash at once, you can still recover the
patch. It wouldn't take much effort to implement this: there's already a
force-quit menu-item that kills the server while keeping the client.
This still wouldn't get you exactly where you were before the crash, in
the same way that closing and reopening any patch will lose object state.
> int main() {int i = -1; while (i) i--; exit(0);}
> $ gcc -o test test.c
> $ time ./test
> real 0m10.677s
> user 0m9.437s
> sys 0m0.048s
This is probably right. To be sure that nothing is optimised out, you
should use the "volatile" keyword on the i variable, but because the
default is "no optimisation" it doesn't make a difference. It would if you
wanted to measure something both optimised and not too much optimised so
that it is representative of the minimum time it would take if something
else would be done inside of the loop.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
More information about the Pd-list
mailing list