On 21 Nov 2003 at 13:48, [EMAIL PROTECTED] wrote: > I don't think I understand what Gordon is suggesting -- and this is > partly because there are still some things I don't understand about > Python scoping, reference counting, etc. and partly because there are > some things I don't understand about how Metakit does things. > > However, opening up potentially a fairly large number of storages which > you stuff into what are basically global variables just so they don't > disappear on you, and leaving those things open (and presumably using > memory to at least some degree) doesn't seem to be an especially good > practice. You wouldn't normally open a file when you need it and then > just leave it open until you terminate the entire application (if, for > example, the application manipulates a large number of files).
That depends on the size of the file, the number of times you need something from it, the relative expense of memory vs file handles. > You > wouldn't normally do that with a database either. Huh? In a typical RDB the expense of opening is someplace between large and huge. > The 'open/use/close' > model generally has benefits that the 'open and just leave open' model > does not. And this feels like the same kind of thing to me. But > perhaps I misunderstand. Memory mapped files typically use the OS's swap mechanism. Keeping it open just tells the OS to manage the "real" vs "virtual" memory usage - which it does more efficiently than a programmer can. > The particular situation confronting me is where I open an existing > storage and get its view. That view (and the storage) are then never > changed (think of it as read-only), but a number of other views are then > created based on that one and passed to a variety of classes for further > processing and display. Some of these views may then be "saved" at some > point, but not in that original storage. But many will be transient and > only for intermediate purposes. So I'm not really interested in doing a > commit() on any of these. > > Intuitively, it seems as though a storage ought to remain in existence > so long as you have a reference to a view that is in any way based on > that storage. And the storage ought to go away when you no longer have > any references to it (however indirectly). This just seems to be a > description of the memory management (object management, reference > management) model on which the language is based. If for some reason > (having to do with the underlying implementation of some of the objects > involved) this is not possible, then these objects just seem to violate > that fundamental model. It seems as though in the current situation > views and storages fall into this class. I can live with that. But > ideally it seems as though it shouldn't be the case. > > On the other hand, it may be that I'm just not thinking along the right > lines here. I can understand the surprise factor. But try this: If views held a reference to the storage, then storage = None wouldn't kill the storage. You'd have to have a storage.close() which should either close all views (so you'd have storage -> view references, ie, circular), or perhaps throw an exception if any view is still open, or just silently wait for GC (which would mean we'd have to make storage objects GC containers). You'd still have surprises. And other than making so you don't have to explicitly keep a reference to the storage, it would have no effect on memory or resource consumption except make it harder to directly control it. -- Gordon _______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
