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

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20150306/1bf3869e/attachment.html>