<div dir="ltr">Update: I eliminated everything I could from the Shreds that were being Sporked, and I still get the exact same error (at exactly 147 Shreds.)<div><br></div><div>Here is what I shortened the Shreds to:</div>
<div><span class=""><br></span></div><div><span class="">fun</span> <span class="">void</span> Blink()</div><div>{</div><div><span class=""> </span>while<span class="">( </span>true<span class=""> )</span></div><div> {</div>
<div><span class=""> 50</span>::<span class="">ms</span> => <span class="">now;</span></div><div> }</div><div>}</div><div><br></div><div>
<div><span class="">fun</span> <span class="">void</span> LFOMod()</div><div>{</div><div><span class=""> </span>while<span class="">( </span>true<span class=""> )</span></div><div> {</div><div><span class=""> 50</span>::<span class="">ms</span> => <span class="">now;</span></div>
<div> }</div><div>}</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 4:22 PM, Ryan Supak <span dir="ltr"><<a href="mailto:ryansupak@gmail.com" target="_blank">ryansupak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the thorough reply. I'm doing one safer, even than "voice stealing": each Spork is, at most, reconfiguring a single global oscillator.<div>
<br></div><div>Attached is the entire source. Lines 128-142 contain initialization code that creates a Shred to make an LED blink by sending a MIDI message within a time loop, and another Shred that sets the frequency of an LFO, polls it every ten milliseconds, and sends some Serial output based on the LFO position.</div>
<div><br></div><div>Anytime that the parameters controlling the blinking rate and the LFO rate/phase have occasion to change (when MIDI events come in to change them), the "old" Shreds are Machine.Remove'd and they're recreated immediately following. You can see this at lines 343 and 589.</div>
<div><br></div><div>Notice that the LFOMod function and the Blink function aren't creating anything new (with the exception of local arguments being instantiated), but if you think those local arguments could be causing my problem I'll eliminate them too.</div>
<div><br></div><div>Please see the attached.</div><span class="HOEnZb"><font color="#888888"><div>rs</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jun 23, 2014 at 11:59 AM, Perry R Cook <span dir="ltr"><<a href="mailto:prc@cs.princeton.edu" target="_blank">prc@cs.princeton.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have lots of programs that spork hundreds or thousands<br>
of shreds without this error. So, without seeing your<br>
code, my guesses (and questions) are as follows:<br>
<br>
Are you running this on a small memory architecture? Since<br>
you say headless, I'm guessing maybe Raspberry Pi? It<br>
could be that you're running out of memory, so see next<br>
question.<br>
<br>
Does the shred that you're sporking declare new UGs or<br>
require memory to be allocated (arrays, lots of string<br>
manipulation, etc.)? In general, this is a bad idea if you<br>
can avoid it. ChucK does no garbage collection, which<br>
means that you need to be cautious about declaring memory.<br>
<br>
So even a shred as simple as:<br>
<br>
fun void mySine() {<br>
SinOsc s => dac;<br>
Math.random2f(100,1000) => s.freq;<br>
second => now;<br>
s =< dac;<br>
}<br>
<br>
will eat up memory, because even though the SinOsc<br>
is unchucked and never computes again, the memory<br>
for that structure is still around. We want, someday<br>
to make ChucK a proper garbage collecting language,<br>
but it's hard, especially for real-time systems.<br>
<br>
If this turns out to be your issue, then one way to<br>
handle this is to make a global pool of fixed<br>
resources and have your shred grab from that.<br>
Like classic "round robin voice stealing" in<br>
synthesizers:<br>
<br>
SinOsc s[100];<br>
0 => int next2Use;<br>
<br>
fun void mySine() {<br>
next2Use => int thisOne;<br>
1 +=> next2Use;<br>
if (next2Use > 99) 0 => next2Use;<br>
s[thisOne] => dac;<br>
Math.random2f(100,1000) => s[thisOne].freq;<br>
second => now;<br>
s[thisOne] =< dac;<br>
}<br>
<br>
// to test:<br>
while (1) {<br>
Math.random2f(0.01,0.1) :: second => now;<br>
spork ~ mySine();<br>
}<br>
<br>
I just fired up a few dozen of these running in<br>
parallel, VM showed 2600 total shreds running,<br>
no problem (and no clicks or dropouts!!).<br>
<br>
Hope this helps, if none of this applies, then you<br>
may have discovered a strange bug. Source code please,<br>
and we can all scratch our heads on it.<br>
<br>
Thanx!! PRC<br>
<br>
<br>
Today's Topics:<br>
<br>
1. 147th shred removed...segmentation fault? (Ryan Supak)<br>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>