I dont have an issue with this in .NET , memory leaks due to holding long lived unexpected references (events/call-backs) are a much bigger issue . Generally you want to manage your resources carefully , possibly as a pool in your module anyway and not expose this to the user - I think the DirectX wrapper allowed these objects to hold the resources which created issues . So the normal pattern is to create objects passed to other modules with no references to the resources but when these proxy objects are cleaned up you can clean up or re-issue the pool managed resources .
The use pattern with clean up in dispose is pretty good for the other cases but not complicated ones. Ben On Thu, Aug 6, 2015 at 8:10 AM, Jonathan S. Shapiro <s...@eros-os.org> wrote: > Hold up, folks. I think this discussion headed off in the wrong direction, > probably because I asked the wrong question. > > Val: please respond to the list! > > Keean: RAII deals with initialization, not disposal. RAII has nothing to > do with the question. The question has nothing to do with memory cleanup, > so the example of String disposal isn't relevant. GC solves the modularity > problem for memory. I'm asking a question about *other* resources. > > The argument about modularity for memory is that you can't safely call > free() unless you know where your pointer has been, and once you pass a > pointer into a library you don't necessarily know that anymore. GC solves > this, because at the level where GC operates you have visibility into > liveness that extends across module boundaries. > > My question concerns violations of modularity for NON-MEMORY resources. > The substance of my question is: are the modularity issues for NON-MEMORY > resources substantive in current systems, or do existing use patterns deal > with them adequately in practice? The reason I'm asking is that GC > generally is *not* a complete solution for such resources. > > To give one (of several) examples, file handles (or in UNIX: descriptors) > are one of the kinds of resources I'm thinking about. Another example might > be extremely large I/O buffers such as those used in database systems. In > both cases, there are reasons to get rid of the resource fairly promptly. > In the file handle case you just don't have that many to work with; in the > buffer case you are chewing up a very large chunk of real memory that you > want to be able to do custom allocation for. In both cases, GC+finalization > is inadequate because it doesn't provide any guarantee of promptness. This > is why the iDisposable pattern exists in .NET; it lets you explicitly > release resources like this. That is: it lets you manage this class of > resource manually. > > Now the thing is: this sort of manual resource management is a lot like > manual memory management. It may not introduce safety problems, but it has > the same potential for use-after-free etc. And it therefore violates > modularity in the same way that explicit memory management does. > > In some cases, linear types can manage this, but not all. The USE pattern > can also manage many cases, but not all. I'm not looking for a new pattern > in this thread. What I'm trying to ask is whether the *existing* patterns > are good enough to preserve modularity where the use of these resources is > concerned *in practice*? If not, can someone give an example of how > modularity gets violated in common library designs for (say) things like > file handles? > > > shap > > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
