On Mar 21, 11:59 am, "andrew cooke" <and...@acooke.org> wrote: > Aaron Brady wrote: > > My point is, that garbage collection is able to detect when there are > > no program-reachable references to an object. Why not notify the > > programmer (the programmer's objects) when that happens? If the > > object does still have other unreachable references, s/he should be > > informed of that too. > > i think we're mixing python-specific and more general / java details, but, > as far as i understand things, state of the art (and particularly > generational) garbage collectors don't guarantee that objects will ever be > reclaimed. this is a trade for efficiency, and it's a trade that seems to > be worthwhile and popular.
It's at best worthless, but so is politics. I take it back; you can reclaim memory in large numbers with a probabilistic finalizer. The expected value of reclaiming a KB with a 90% chance of call is .9 KB. The allocation structure I am writing will have a very long up-time. I can forcibly reclaim the memory of an object involved in a cycle, but lingering references it has will never be detected. Though, if I can't guarantee 100% reclamation, I'll have to be anticipating a buffer dump eventually anyway, which makes, does it not, 90% about the same as 99%. > furthermore, you're mixing responsibilities for two logically separate > ideas just because a particular implementation happens to associate them, > which is not a good idea from a design pov. I think a silent omission of finalization is the only alternative. If so they're mixed, one way or the other. I argue it is closer to associating your class with a hash table: they are logically separate ideas. Perhaps implementation is logically separate from design altogether. > i can remember, way back in the mists of time I understand they were having a fog problem there yesterday... not to mention a sale on sand. "Today: Scattered showers and thunderstorms before 1pm, then a slight chance of showers." > using java finalizers for > doing this kind of thing. and then learning that it was a bad idea. once > i got over the initial frustration, it really hasn't been a problem. i > haven't met a situation I don't suppose I imagine one. So, you could argue that it's a low priority. Washing your hands of the rare, though, disqualifies you from the associate's in philosophy. I bet you want to meet my customers, too. > where i needed to tie resource management and > memory management together (except for interfacing with c code that does > not use the host language's gc - and i can imagine that for python this is > a very strong (perhaps *the*) argument for reference counting). I'm using a specialized mapping type to implement the back end of user- defined classes. Since I know the implementation, which in particular maps strings to objects, I can always just break cycles by hand; that is, until someone wants a C extension. Then they will want tp_clear and tp_traverse methods. > as an bonus example, consider object caching - a very common technique > that immediately breaks anything that associates other resources with > memory use. I assume your other processes are notified of the cache state. From what I understand, Windows supports /named/ caching. Collaborators can check the named cache, in the process creating it if it doesn't exist, and read and write at will there. > just because, in one limited case, you can do something, doesn't mean it's > a good idea. > > andrew But you're right. I haven't talked this over much on the outside, so I might be missing something huge, and serialized two-step finalization (tm) is the secret least of my worries. -- http://mail.python.org/mailman/listinfo/python-list