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@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users