[chuck-users] osc listener shred woes

Kassen signal.automatique at gmail.com
Mon Apr 28 07:08:02 EDT 2008


2008/4/28 Atte André Jensen
>
> I think you should try adding:
>        1::samp => now;
> 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...
>

The "why" is quite straightforward. Take this example;
-------------------
fun void my_shred()
 {
 <<<"here I am!">>>;
 }

spork ~my_shred();
//code ends here.
---------------

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.

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.

Typically it's wise to use that command right after signalling or
broadcasting a event or sporking a shred.

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.

I hope that clarifies things a bit.

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


More information about the chuck-users mailing list