Jamie Bullock wrote:
static void until_bang(t_until *x) { x->x_run = 1; x->x_count = -1; while (x->x_run && x->x_count) { x->x_count--; outlet_bang(x->x_obj.ob_outlet); usleep(1); } }
I think this is the best idea. But after writing my last post to the list, I started to wonder if Miller had a good reason for not doing this when he wrote the original code?
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 that shouldn't be there. This construct can be used to do something a bunch of times, and as fast as possible. Also, as I have pointed out before, 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].
Just to drive home a point, I measured how long it would take to take an int starting and -1, and decrement it until it gets to 0.
(This system has a dual core Pentium D 2.8 GHz, 2 gigs of ram ...)
test.c:
#include <stdlib.h> #include <stdio.h>
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
So, going back to the original code, the amount of time it takes this construct to finish depends on what you do with outlet_bang(). And really, it's a nice construct to be able to something a bunch of times, as fast as the program can handle.
After all, this is a programming environment. You can write bad code. I have been down this road multiple times before. With an environment like this, you can't try to infer what the user actually meant. I know it would be nice if computers "did you want, not what you say", but implementing that is non-trivial. Personally, I'd rather have deterministic software that does exactly what I say.
So, after going through my own mental exercise to analyze the situation, I now don't think any changes should be made at all.
If anything, it probably just hints at a potential Pd architecture improvement, where patch processing should be premptable, so that the GUI can continue to be responsive, regardless of how the patch is written ...
-- Russell
-- Russell Bryant