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