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
