Felix scripsit: > This means the number of finalizers is limited to (currently) 4096. Code > that produces many finalizers must make sure they are triggered (and > thus un-registered) fast enough.
Ick, ick, ick. This is a horrible solution. The main use of finalizers that I've ever had is when dealing with objects allocated by C libraries; a pointer object wrapped in a finalizer insures that when the foreign object is no longer interesting to the Scheme side, it is properly freed, which may or may not involve calling free(). Having a fixed low limit on the number of finalizers means that this sort of design is not practical: you wind up being better off with larger-grain foreign objects and more C code to access their insides. That's un-Schemey. > Note that the "-:f" runtime option can be used to change the number > of available finalizers. This helps a little, but not much, because it's basically guesswork what to set the option to, and it may vary greatly depending on the input, leading to programs that work fine and then suddenly crash. Why does there have to a be a persistent array of all finalizers anyway? The garbage collector itself can find them during the mark phase. -- John Cowan [email protected] http://ccil.org/~cowan This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
