2010/9/7 Kassen
<signal.automatique@gmail.com>
2010/9/7 Tambet
<qtvali@gmail.com>
I now notice I mis-spelled your name a few times; I blame my dyslexia combined with English lacking a gender-neutral pronoun.
At least you hadn't to tell it out loud :)
You mostly answered everything ..I meant closing shreds and collecting threads.
Great! Threads we don't need to worry about as ChucK runs in a single (OS) thread. Shreds as objects seem to be collected. If you are having specific issues there shout.
Ok, that's nice to know ..I have very imprecise memory monitor, will fix that.
Indeed, but maintaining and updating the manual takes time and for this case it might be more worthwhile to spend that time fixing the issue instead. Sadly it's not that clear when we will have proper GC.
I strongly suggest looking into efforts of Go. Another possibility is to implement protocol for Java garbage collector? - they are pluggable and there are many.
Google Go, in nearby future, should have very powerful multithreaded GC.
Our case is rather specific. For multi-threading (which we don't yet do) a analysis needs to be made about what parts depend on what others. In ChucK this graph may change rather dramatically as UGens get re-connected. Multi-threading in this context is non-trivial.
Multi-core'ing.
I would like to do some analysis for that. I am very good analyst as people say. I think I could come out with robust solution if I had enough data about how it exactly works and which are the possibilities - for example, this redirecting. I have painted schemes for garbage collectors ..anyway, I'm stuck enough with time that I could not code it alone :) - but maybe I could create a coherent architecture document as a starting point for review.
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users