[chuck-users] Returning a Shred and crashing Chuck

[Kassen]

2008/6/13 mike clemow <gelfmuse at gmail.com>:

>
> Yes, I forgot to mention that!  Crazy...  I guess I'll manually
> unchuck the SinOsc for now.  I'll have to check if that happens with
> other UGens...
>

Unchucking unused Ugens it good form anyway. Wherever you can afford to I'd
do that because it saves CPU. IT tisn0/t alway appropriate because with some
Ugens or systems of Ugens the code need not be aware of when the Ugen is
"done", for example with the physical models in the STK.


>
> Meanwhile, if I unchuck that SinOsc from the dac it works in the sense
> that the SinOsc objects don't add up, however, only if the shreds
> finish executing.  If I remove the parent while one of the sporked
> shreds is still running, one sine keeps going.  Ostensibly because the
> last shred hasn't finished and the unchuck line hasn't run.  This
> makes me really wish I could define code that would be called when a
> shred exits.  That would be a neat feature...
>

Yes, quite weird and I can't remember this being like that in the past. This
is truely arcane stuff and likely only Ge knows.... But I have a suspicion.
Clearly a outside reference to a shred affects how it deals with cleanup. I
suspect this has to do with Ge having been working at garbage collection
(which also works with references... or at least will). I suspect what we
are seeing might be a trace of the start of a GC framework. In that case we
found a bug in a feature that's not even here yet... That would be quite
funny.

Disclaimer; this is complete speculation and not of any practical use.

Code to be run when a shred exits is a interesting idea but I suspect it's
asking for trouble. Because a shred has it's own namespace which is
obviously gone when the shred is such code would probably need to be run
*before* it exits and after it get's it's exit notice.... but then what if
this code does stuff like advance time or (worse yet!) call for the exit of
the same shred? I suspect this would be asking for stuck VM's and confused
shredulers. I'd rather have proper cleanup. I'd also be quite interested in
Shred type objects giving access to that shred's name-space like this;

fun void foo()
{
3 => int value;
while (second => now) <<< value >>>>;
}

spork ~ foo() @=> Shred bar;

4::second => now;

//modest proposal starts here
5 => bar.value;
hour => now;

This would also enable us to run manual cleanup; either from the last lines
of the shred's code (asuming it's not a infinite loop) or from the shred
that calls for it's exit, right before the exit call.

Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080613/2e929fb9/attachment.html>