[chuck-users] is shred running? (Atte)

Spencer Salazar spencer at ccrma.stanford.edu
Fri Mar 6 17:28:22 EST 2015


Hmm, let me clarify: semantically the difference between the two is
"undefined." The extent to which that difference (if any) affects actual
ChucK code can be considered a bug. Though its partially a bug in the
language specification, which makes it harder to fix, compared to a bug in
the implementation.

I was more speaking to Atte's question about what might account for the
differing results he was seeing with those two methods. It just so happens
that Machine.remove is implemented such that it works almost exactly chuck
- [shredid]. Whether or not this is desirable (or useful, etc.) can be
debated, along the lines you have mentioned below.

spencer


On Fri, Mar 6, 2015 at 1:07 PM, Kassen <signal.automatique at gmail.com> wrote:

>
> Spencer wrote;
>
>
>>
>> Hmm, it would be nice if there was no difference. But there is a
>> difference, internally, and it appears that is leaking out of the
>> abstraction so to speak. So basically .exit() appears to terminate the
>> shred immediately whereas Machine.remove() waits until all shreds have
>> finished executing for this sample, i.e. all shreds are waiting => now. At
>> least that is what I am interpreting from the source code.
>>
>>
>> Ok... but if we run Machine.remove() from shred A then I think we can be
> absolutely sure shreds B, C and D will be waiting for something
> (potentially shred A yielding), because we have no real concurrency and we
> can also be sure the ugen graph is not being pulled by the dac at this
> moment for the same reason.
>
> I can see this mattering in the case of "%chuck - [my_shred]" which could
> be executed while the VM is doing any of the things it can do. In that case
> we'll likely want to wait for a moment to avoid stuff like half of a
> operation being left on the stack, but in the case of commands coming from
> shreds I think we can be sure other shreds are not in the middle of
> something.
>
> I'm not sure how that would have to deal with the need to be able to kill
> shreds stuck in a infinite non-time-advancing loop from the console though.
>
> Maybe I am missing something and there is a reason to have the termination
> of shred B from shred A postponed until A yields in some cases?
>
>
> Yours,
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
Spencer Salazar
Doctoral Candidate
Center for Computer Research in Music and Acoustics
Stanford University

spencer at ccrma.stanford.edu
+1 831.277.4654
https://ccrma.stanford.edu/~spencer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20150306/7f6655f0/attachment-0001.html>


More information about the chuck-users mailing list