Great! Anyone else? :) More rhetoric: Isn't this almost a practical necessity for applications that want fine-grained (millisecond) timeouts SRFI 21? I don't see garbage collection mentioned at all in SRFI 21 or 18, and I agree that it is a theorectically transparent issue. But it could easily be a major practical issue for long-running soft-realtime applications that have hard service-level agreements on latency. Other systems (e.g. Orbitz, point #9 in http://www.paulgraham.com/carl.html) work around this by having custom versions of cons etc. that use statically-sized pools, and they die if the pool is consumed (i.e. a standard embedded-systems approach). It would be great to not have to go that route! Thanks, Chris ----- Original Message ----- From: "david rush" <kumoyuki@gmail.com> To: "Marc Feeley" <feeley@iro.umontreal.ca> Cc: <gambit-list@iro.umontreal.ca> Sent: Saturday, December 31, 2005 10:21 AM Subject: Re: [gambit-list] Incremental garbage collector On 12/31/05, Marc Feeley <feeley@iro.umontreal.ca> wrote:
Unfortunately the incremental collector described in the ISMM98 paper has suffered from bit-rot, and is not distributed with Gambit. I may resurect the code if there is sufficient interest in this (I know some people are interested in developing video-games with Gambit, and an incremental GC would be very useful for this).
For reasons other than video games, count my vote as interested :) david rush -- DIsruptive Technology! _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list