<div class="gmail_quote">On 6 September 2010 23:55, Hans Aberg <span dir="ltr"><<a href="mailto:haberg-1@telia.com">haberg-1@telia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">GC ought to be wholly independent of the ChucK thread that syncs the music, since it is only about collecting unused memory. Suppose you have a collecting GC that runs nicely in the sense that it does not interrupt ChucK perfect timing. Then it could within that limitation collect whenever it gets some time from the system to do it in its own thread.</div>
</blockquote><div><br></div><div>Both real-time and multi-threaded GC are still considered *hard* issues in the PL community. In a multi-threaded app, you have to address how to keep the mutator alive and kicking during the GC cycle (since the allocation graph is clearly a shared data structure), and in a  real-time app, you have to address the problem of deadlines even though the mutator may cause very uneven GC loads. </div>
<div><br></div><div>It does turn out that both problems are loosely related, but it's not at all easy to adress the issues in any given application. ChucK's reference-counted approach is one that is works quite well in real-time systems, but reference-counting has the downside that it can be very buggy if it is implemented manually, and it is quite easy to cause naive reference counting to leak (so you still have to be acutely aware of the object life-cycle).</div>
<div><br></div><div>david</div><div>-- </div></div>GPG Public key at <a href="http://cyber-rush.org/drr/gpg-public-key.txt">http://cyber-rush.org/drr/gpg-public-key.txt</a><br>