[PD] What exactly is a "stack overflow" ?

Russell Bryant russell at russellbryant.net
Thu Dec 20 17:41:26 CET 2007


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




More information about the Pd-list mailing list