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