Hello all, As ChucK is intended to be an "on the fly" tool for sound generation, I was wondering if it would be possible if the compiler could detect infinite loops that DO NOT advance time. I am thinking about this more from a practical stand point that when some new code is being added to ChucK, if a loop is entered that does not advance time, nor yeild control to another thread, it will SEIZE the machine, with the only recourse is rebooting. While this is practical, I know that it would be one of those feature requests that would be low priority. I only make the recommendation because over the weekend, I was playing with ChucK and ran accross this very problem. I would think that in performance, it would not really be practical to have to reboot. At the same time, I wonder how many performances would rely on entering raw code, instead of loading files. Thanks, Mike
From the famous halting problem, no compiler or any program can detect an infinite loop. Thus we can't detect infinite loops that do or do not advancce time.
PRC On Mon, 13 Feb 2006, Mike McGonagle wrote:
Hello all,
As ChucK is intended to be an "on the fly" tool for sound generation, I was wondering if it would be possible if the compiler could detect infinite loops that DO NOT advance time. I am thinking about this more from a practical stand point that when some new code is being added to ChucK, if a loop is entered that does not advance time, nor yeild control to another thread, it will SEIZE the machine, with the only recourse is rebooting.
While this is practical, I know that it would be one of those feature requests that would be low priority. I only make the recommendation because over the weekend, I was playing with ChucK and ran accross this very problem. I would think that in performance, it would not really be practical to have to reboot. At the same time, I wonder how many performances would rely on entering raw code, instead of loading files.
Thanks,
Mike _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
While I understand that it wouldn't be possible to catch ALL loops
like this, but I would think that a compiler, at least in a while loop
(and possibly a for loop), could check to ensure that these loops
contain some increment in 'now', as well as ensuring that the control
variable in loop statement at least has some sort of assignment within
the loop. This would NOT catch all possible occurances, so maybe it is
not worth the effort.
Just a curiousity, rather than a "request"...
Thanks,
Mike
On 2/13/06, Perry R Cook
From the famous halting problem, no compiler or any program can detect an infinite loop. Thus we can't detect infinite loops that do or do not advancce time.
PRC
On Mon, 13 Feb 2006, Mike McGonagle wrote:
Hello all,
As ChucK is intended to be an "on the fly" tool for sound generation, I was wondering if it would be possible if the compiler could detect infinite loops that DO NOT advance time. I am thinking about this more from a practical stand point that when some new code is being added to ChucK, if a loop is entered that does not advance time, nor yeild control to another thread, it will SEIZE the machine, with the only recourse is rebooting.
While this is practical, I know that it would be one of those feature requests that would be low priority. I only make the recommendation because over the weekend, I was playing with ChucK and ran accross this very problem. I would think that in performance, it would not really be practical to have to reboot. At the same time, I wonder how many performances would rely on entering raw code, instead of loading files.
Thanks,
Mike _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Help the Environment, Plant a Bush back in Texas!
Perry, I, and others have thought about alternatives for alleviating this chuckian "non-halting" problem where infinite loops that do not advance time can "seizes" the machine on some platforms, due to the priority boost on the audio. One thing we have going for us is that we don't need necessarily need to detect infinite loops, we just need to determine (at runtime) when some shred has been executing for "way too long", in which case a counter-measure can be activated (such as lower the priority and allow the operating system to breathe). A watch-dog mechanism for monitoring audio underflow and adaptively changing the priority may be a reliable way to address this. This is pretty important and is high priority on the TODO list. Best, Ge! On Feb 13, 2006, at 1:59 PM, Perry R Cook wrote:
From the famous halting problem, no compiler or any program can detect an infinite loop. Thus we can't detect infinite loops that do or do not advancce time.
PRC
On Mon, 13 Feb 2006, Mike McGonagle wrote:
Hello all,
As ChucK is intended to be an "on the fly" tool for sound generation, I was wondering if it would be possible if the compiler could detect infinite loops that DO NOT advance time. I am thinking about this more from a practical stand point that when some new code is being added to ChucK, if a loop is entered that does not advance time, nor yeild control to another thread, it will SEIZE the machine, with the only recourse is rebooting.
While this is practical, I know that it would be one of those feature requests that would be low priority. I only make the recommendation because over the weekend, I was playing with ChucK and ran accross this very problem. I would think that in performance, it would not really be practical to have to reboot. At the same time, I wonder how many performances would rely on entering raw code, instead of loading files.
Thanks,
Mike _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hey, if it fixes the problem of not being able to force quit ChucK,
then I will take anything...
Thanks,
Mike
On 2/13/06, Ge Wang
Perry, I, and others have thought about alternatives for alleviating this chuckian "non-halting" problem where infinite loops that do not advance time can "seizes" the machine on some platforms, due to the priority boost on the audio. One thing we have going for us is that we don't need necessarily need to detect infinite loops, we just need to determine (at runtime) when some shred has been executing for "way too long", in which case a counter-measure can be activated (such as lower the priority and allow the operating system to breathe). A watch-dog mechanism for monitoring audio underflow and adaptively changing the priority may be a reliable way to address this.
This is pretty important and is high priority on the TODO list.
Best, Ge!
On Feb 13, 2006, at 1:59 PM, Perry R Cook wrote:
From the famous halting problem, no compiler or any program can detect an infinite loop. Thus we can't detect infinite loops that do or do not advancce time.
PRC
On Mon, 13 Feb 2006, Mike McGonagle wrote:
Hello all,
As ChucK is intended to be an "on the fly" tool for sound generation, I was wondering if it would be possible if the compiler could detect infinite loops that DO NOT advance time. I am thinking about this more from a practical stand point that when some new code is being added to ChucK, if a loop is entered that does not advance time, nor yeild control to another thread, it will SEIZE the machine, with the only recourse is rebooting.
While this is practical, I know that it would be one of those feature requests that would be low priority. I only make the recommendation because over the weekend, I was playing with ChucK and ran accross this very problem. I would think that in performance, it would not really be practical to have to reboot. At the same time, I wonder how many performances would rely on entering raw code, instead of loading files.
Thanks,
Mike _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Help the Environment, Plant a Bush back in Texas!
participants (3)
-
Ge Wang -
Mike McGonagle -
Perry R Cook