Hmm.. wasn't some kind of watchdog thing added to catch stuff like this: while (true) { } ...? That ought to catch Eduard's problem as well, I would think. Maybe it's some kind of option to the chuck application? /Stefan On Mon, Nov 10, 2008 at 1:05 PM, lucas samaruga wrote:

Hello

I think it's a logic problem, ChucK can't worry about everything. Other example, If you yiel two shereds in a particular way the time don't pass (I can't code it right now). Maybe I'm wrong...

Cheers Lucas

2008/11/9, eduard aylon :

...

Sorry list for bombing you with so many questions, but got this funny one, which I thought would be interesting to post. The patch below loops endlessly although no while(true) loop exists in the "main". If you try the patch, be warn that your computer may (or may not) become unresponsive. The code makes sense, and the behaviour as well, but should chuck throw a warning when something like this happens? I came up with this, while trying to have a process for reading and another for writing, but didn't want to advance time in any of them.

eduard

class mySpork { Event write; Event read;

fun void start(){ read.signal(); <<<"started">>>; }

fun void Write() { // NOTE: time is not advanced in this function while(true) { write => now; //<<< "writing" >>>; read.signal(); } }

fun void Read() { // NOTE: time is not advanced in this function while(true) { read => now; //<<< "reading" >>>; write.signal(); } } }

mySpork myspork; spork~myspork.Read(); spork~myspork.Write(); me.yield(); myspork.start(); <<< "loops forever">>>; 1::second => now; <<< "and never gets here">>>;

_______________________________________________ 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

-- Release me, insect, or I will destroy the Cosmos!

Hi and wath is hapend here? // Only to make sound SinOsc s => dac; 0.1 => s.gain; fun void funcion() { while( true ) { <<< "func, me.id() = ", me.id() >>>; 1::second => now; } } spork ~ funcion() @=> Shred @ sfun; // This block the shreds // The .yield is called externally sfun.yield(); //me.yield(); // not necessary <<< "main, me.id() = ", me.id() >>>; 1::second => now; <<< "end" >>>; 1::ms => now; Cheers (remember I don't speak English so good :) 2008/11/10, Kassen :

2008/11/10 Stefan Blixt

...

Hmm.. wasn't some kind of watchdog thing added to catch stuff like this:

while (true) { }

...? That ought to catch Eduard's problem as well, I would think. Maybe it's some kind of option to the chuck application?

Well, the watchdog doesn't actually catch stuff like that. What I think the Watchdog does is check for the VM being very late delivering samples to the soundcard and if/when it is it offers you to abort the current shred (being the one that has the CPU at that time.

For me on Linux in the Mini (I just tried) the watchdog does catch Eduard's code.

Watchdog will also "catch" situations that are kosher yet take a lot of CPU, for example a big calculation meant to fill a sound buffer or something along those lines. In that case it may make sense not to abort the Shred and simply wait while dreaming of a faster computer.

Interestingly, when something claims the whole soundcard while the Mini is running (Skype just did this for me yesterday) it will aparently prevent the Mini from handing out samples, even with a empty VM, and watchdog will offer to remove the current shred even if there is none.

Wtachdog is a very simple tool, a emergency break. It's no substitute for analysing code nor could it be.

I hope that helps, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users