RAII also solves this without GC, and works for all resource types (that I can think of right now).
Keean. On 5 Aug 2015 2:40 pm, "Jonathan S. Shapiro" <[email protected]> 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? > > > 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
