2008/4/28 Atte André Jensen <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think you should try adding:<br>
1::samp => now;<br>
here (right after broadcast'ing). Not sure why, but it seems that handling more events in the same time-slice is problematic (or I did a mistake similar to yours). My problem wasn't seg faults, but missed events, so I might be wrong, but it might be worth a try...<br>
<font color="#888888">
</font></blockquote><div><br>The "why" is quite straightforward. Take this example;<br>-------------------<br>fun void my_shred()<br> {<br> <<<"here I am!">>>;<br> }<br></div></div><br>
spork ~my_shred();<br>//code ends here.<br>---------------<br><br>This will never print the line. Why not? Well, once our code starts running it will keep doing so until it either advances time which gives other shreds a chance to run or it reaches the end. While it is running no other shreds do anything. Here the mother shred reaches her end and so exits and takes the child with her so the child never runs.<br>
<br>The solution is "me.yield()" which gives other shreds (and their events and whatever) a chance to run yet doesn't advance time for the mother.<br><br>Typically it's wise to use that command right after signalling or broadcasting a event or sporking a shred.<br>
<br>Generally speaking; ChucK manages a lot of the issues with concurrency for us but it still needs some care and attention because it's still a somewhat hard subject, even when it's made this friendly. I think that's good; ChucK's timing is completely deterministic and does exactly what we tell it but from time to time that means being quite explicid if we want it to behave.<br>
<br>I hope that clarifies things a bit.<br><br>Yours,<br>Kas.<br>