>> 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().
It probably isn't even a solution. I don't disagree with you here. > > 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. It probably is. > >> 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. Yep. Just like running out of memory. There always will be some hard limits. > > 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. It is much more complicated than that (see my reply to Peter). cheers, felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
