On Thu, Jul 06, 2023 at 02:51:43PM +0200, felix.winkelm...@bevuta.com wrote: > That is indeed a shortcoming of the API. I must say that I'm not > too keen on the "guardian" approach, though, or your suggested hacky > workaround. There would be too many meanings attached to the > argument for the polling procedure.
I agree, which is why I called it hacky. > I also don't like the MIT apporach, since our very basic > "set-finalizer!" has worked fine so far (with the execution context > being the main problem). Yeah, MIT's is rather heavy-handed. Perhaps simply we can just return two values? The first a polling procedure and the second a procedure to add new objects to the finalizer? You can just receive the polling procedure in a single-value context and ignore the object-adder if you don't want to use it. Alternatively, make-finalizer could return a new structure type that represents the finalizer. It could just be a wrapper for the queue internally. We'd have to add a getter and an adder procedure that accepts this new object type (and perhaps a predicate). > > Separating the collectable object from the context prevents the > > collected object from re-entering the live system through the > > finalization procedure (it may set! some variable to it, for example > > and that's not desirable). Apparently, this makes ephemerons easier to > > implement. > > I found this through Taylor Campbell's comment on Andy Wingo's blog post: > > https://wingolog.org/archives/2022/10/31/ephemerons-and-finalizers > > I don't quite understand why many APIs are so afraid of retaining > the finalized object. The point is becoming aware of the object > being reclaimable. If it survives yet another GC cycle, so what? This would be problematic if the finalizer has run and deleted the foreign object, while there are still weak references that hold onto the object. This has then become invalid/inconsistent. And vice versa, if there are weak references which are now broken, and the finalizer restores the object, this might cause different kinds of inconsistencies to arise. > Unless we are severely memory-constrained and must at all costs release > the object, I see no need in separating object and context for > finalization. I don't think this separation was ever about memory efficiency. > Moreover, there may be cases when we may need full access > to the object to perform our finalization action. Yeah, hiding the object could be problematic if it holds onto several foreign objects that all have to be cleaned up. > > Now I think this API is rather heavy-handed, but perhaps we can settle > > on some sort of middle ground. I also think that maybe separating the > > finalization object from the "context" is too late for us, unless we > > decide to rework the set-finalizer! API as well for CHICKEN 6. > > Indeed. I wouldn't want to touch the underlying machinery. it works > pretty well, I think. Agreed. > [ event queue API ] > That sounds good, and I understand the motivation but I don't want to > touch the scheduler, to be honest. The UTF transition is already enough > work as it is. The original subject is merely a question of API choice, > let's not try to fix everything right now. Like I said, just a brain dump. Perhaps something to keep in mind for CHICKEN 7. But as we design a new API we'd do well to make such a change possible without too many changes in user code. > I will try to come up with something better, to allow adding objects > to an existing finalizer. Looking forward to it! Cheers, Peter
signature.asc
Description: PGP signature
