On Wed, 2015-08-05 at 06:40 -0700, Jonathan S. Shapiro wrote: > I've been listening to some talks on GC, and they raise some questions in > my mind about resource management. I'm not focused on the memory part here, > so much as the management of *other* resources. I haven't done any > programming "in the large" using GC-style resource management. > > Patrick Dessault notes, correctly, that GC makes things modular. He means > this in the sense that the desire for opaque (or more precisely: oblivious) > behavior across a module boundary is violated by explicit memory > management; we can't release memory when we don't know what's been done > with it, and we don't have any good ways to specify the contract at the > module boundary. > > So GC solves this for memory, but it doesn't really solve this for other > resources that we might need to allocate and deallocate. Finalizers can do > this, but I there is a general consensus that finalizers should be view as > a "last gasp" recovery mechanism. Mainly because the kinds of resources we > tend to be talking about are both precious (that is: in limited supply) and > coarse (that is: there is a lot of incentive not to hold them longer than > we need them). This how we get to patterns like the destroy/finalize > pattern that exists in .NET and elsewhere. > > But it seems to me that this leaves us with the modularity problem > unsolved. Improved, certainly, but unsolved. > > What's the sense of things on this? Is this viewed as a real issue in > practice?
for me it is only an issue in realtime if GC pauses, at a minimum: are the pauses predictable? better no pause at all so that you don't risk to pause at the wrong moment... > > shap > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
