<div class="gmail_quote">2010/9/7 Kassen <span dir="ltr"><<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br><br><div class="gmail_quote">2010/9/7 Tambet <span dir="ltr"><<a href="mailto:qtvali@gmail.com" target="_blank">qtvali@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div style=""><div>[Redirect from Tambet.]</div></div></blockquote><div><br></div><div>I now notice I mis-spelled your name a few times; I blame my dyslexia combined with English lacking a gender-neutral pronoun.<br></div>

</div></blockquote><div><br>At least you hadn't to tell it out loud :)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">

<div> You mostly answered everything ..I meant closing shreds and collecting threads.<br>
 <br></div><div>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.<br></div></div></blockquote><div>

<br>Ok, that's nice to know ..I have very imprecise memory monitor, will fix that.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="gmail_quote"><div>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.</div>

</div></blockquote><div><br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div class="gmail_quote"><div><div> </div></div><div>Google Go, in nearby future, should have very powerful multithreaded GC.<br>


 <br></div></div></div></blockquote><div><br></div></div><div>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.</div>

</div></blockquote><div><br>Multi-core'ing.<br><br>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.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">
<div><br></div><div>Yours,</div><div>Kas.</div></div>
<br>_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
<br></blockquote></div><br>