Keeping it brief you use RAII for file handles too, and they get closed on exceptions due to stack unwinding.
So you would still use RAII for exception safe handling of non-memory resources like file handles, even if you had GC for memory. Keean. On 5 Aug 2015 11:10 pm, "Jonathan S. Shapiro" <[email protected]> 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 > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
