[chuck-users] Is this possible?

[Mike McGonagle]

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 <gewang at cs.princeton.edu> wrote:
> 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 at lists.cs.princeton.edu
> >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >>
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>


--
Help the Environment, Plant a Bush back in Texas!