I&#39;m a bit intrigued by this behaviour, so I felt like testing what actually happens when a shred exits.<div><br></div><div>Here&#39;s a little test program:</div><div><br></div><div><div>SinOsc @ sinosc;</div><div><br>
</div><div>fun void hello() {</div><div>        SinOsc @ localSinOsc;</div><div>        new SinOsc @=&gt; localSinOsc;</div><div>        localSinOsc @=&gt; sinosc;</div><div>        localSinOsc =&gt; dac;</div><div>        1::second =&gt; now;</div>
<div>        &lt;&lt;&lt; &quot;Mark 1b&quot; &gt;&gt;&gt;;</div><div>}</div><div><br></div><div>spork ~ hello();</div><div>&lt;&lt;&lt; &quot;Mark 1&quot;&gt;&gt;&gt;;</div><div>0.5::second =&gt; now;</div><div>&lt;&lt;&lt; &quot;Mark 2&quot;&gt;&gt;&gt;;</div>
<div>1000 =&gt; sinosc.freq;</div><div>1::second =&gt; now;</div><div>&lt;&lt;&lt; &quot;Mark 3&quot;&gt;&gt;&gt;;</div><div>2000 =&gt; sinosc.freq;</div><div>1::second =&gt; now;</div><div>sinosc =&gt; dac;</div><div>&lt;&lt;&lt; &quot;Mark 4&quot;&gt;&gt;&gt;;</div>
<div>while (true) {</div><div>        1::day =&gt; now;</div><div>}</div><div><br></div><div>This will run without error. At Mark 1b it goes silent (the SinOsc creating shred exits). At 3 it writes to that sinosc that has been stored outside the shred without generating a NullPointerException, and at 4 it turns the sinosc on again by chucking it to dac.</div>
<div><br></div><div>This means that UGens aren&#39;t necessarily destroyed by a shred that exits, but it will diconnect them from the graph connected to dac.</div><div><br></div><div>Here&#39;s a tweaked version of the same program:</div>
<div><br></div><div><div>SinOsc @ sinosc;</div><div><br></div><div>fun void hello() {</div><div>        SinOsc @ localSinOsc;</div><div>        new SinOsc @=&gt; localSinOsc;</div><div>        localSinOsc @=&gt; sinosc;</div>
<div>        1::second =&gt; now;</div><div>        &lt;&lt;&lt; &quot;Mark 1b&quot; &gt;&gt;&gt;;</div><div>}</div><div><br></div><div>spork ~ hello();</div><div>&lt;&lt;&lt; &quot;Mark 1&quot;&gt;&gt;&gt;;</div><div>0.5::second =&gt; now;</div>
<div>&lt;&lt;&lt; &quot;Mark 2&quot;&gt;&gt;&gt;;</div><div>sinosc =&gt; dac;</div><div>1::second =&gt; now;</div><div>&lt;&lt;&lt; &quot;Mark 3&quot;&gt;&gt;&gt;;</div><div>2000 =&gt; sinosc.freq;</div><div>1::second =&gt; now;</div>
<div>sinosc =&gt; dac;</div><div>&lt;&lt;&lt; &quot;Mark 4&quot;&gt;&gt;&gt;;</div><div>while (true) {</div><div>        1::day =&gt; now;</div><div>}</div><div><br></div><div>Here the sinosc isn&#39;t chucked to dac in the shred that creates it, but it still disconnects it. So the shred keeps track of what UGens have been created inside it, and makes an effort to disconnect them when it exits.</div>
<div><br></div><div>I&#39;m not going to argue right or wrong here - clearly there is an idea behind disconnecting UGens in shreds that exits, and this is as good an implementation of that as I can see. The alternatives would be to either make the sinosc variable corrupt (point to a deallocated piece of memory), or allow a shred to assign null to variables outside its scope, which doesn&#39;t feel like a sensible thing to do.</div>
<div><br></div><div>Sorry for going a bit OT (mail threads can be forked), but I&#39;ve always found compiler theory fascinating in a hobbyist kind of way. :)</div><div><br></div><div>/Stefan</div></div></div><div><br><div class="gmail_quote">
2009/10/9 Kassen <span dir="ltr">&lt;<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div class="gmail_quote">So the moral of the story: if you terminate a shred via exit(), it does NOT get the benefit of a standard shred clean-up.<br>

<br></div></blockquote></div><div><br>I&#39;d like to briefly return to this.<br><br>We&#39;re all human with the doubts and insecurities that come with that and the VM will come across at authoritative even while it&#39;s misbehaving.<br>

<br>It can be hard when you&#39;re not that experienced with ChucK (yet) to say &quot;I&#39;m right and ChucK is wrong&quot;, I know I found that hard and would instead blame the issue on me not understanding the syntax, then keep it to myself<br>

<br>I suspect a lot of found bugs go unreported because users blame themselves instead of blaming the VM. In case of doubt; report. It may be a bug (which can go on The List), it might be a issue with the docs (in which case it needs documentation) or you may misunderstand something (in which case you get to learn).<br>

<br>Just wanted to point that out; the VM is wrong quite often.<br><br>Yours,<br>Kas.<br></div></div><br>
<br>_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Release me, insect, or I will destroy the Cosmos!<br>
</div>