Shap said: > > Sandro, David: I disagree somewhat about the simplest model. I'm not aware > of *any* GC model in which release is guaranteed to be prompt for > non-memory resources. If nothing else you can end up with a bug that > preserves a *reachable* cycle, and that stuff will *never* get released. > The ONLY correct model is explicit release for such resources, and once you > do that it no longer matters what the GC framework is where that issue is > concerned. Because of this, I feel that something like unwind-protect or > try-catch-finally is really important to have. There *are* a few programs > that aren't covered by that, but those have to be written with care no > matter what you do. For all of these reasons, the notion of releasing > resources in the finalizer should be viewed as a last-gasp recovery measure > rather than a primary means of resource management. >
Actually, I think you and I agree... mark-sweep-GC for memory-safety... accept that finalizers run in non-deterministic time, and discourage their use, especially for any external resource. Since this is effectively the reality of every memory-safe system (including cycle-finding reference counters) Sandro said: > That's why I said full ref counting, not any of the deferred variants. The > only "complicated" part to explain are why some programs may experience > pauses when collecting a large structure. I wasn't talking about deferred variants. Hybrid refcounting systems with cycle collection essentially use periodic Mark-Sweep to find cycles (not unlike a GC). I'm not aware of any such system which can guarantee deterministic collection of cycles. If there is one, I'd love to be pointed to it.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
