One more note; I tried changing generators to set their gi_frame to None whenever the generator finishes normally or with an error; this eliminated most of the reference cycles, and I was able to make test_generators work correctly with only 3 explicit close() calls, for the "fun" tests that use objects which hold references to generators that in turn reference the object.
So, I think I've got this sorted out, assuming that I'm not doing something hideously insane by having 'has_finalizer()' always check tp_del even for non-heap types, and defining a tp_del slot for generators to call close() in. I ended up having to copy a bunch of stuff from typeobject.c in order to make this work, as there doesn't appear to be any way to share stuff like subtype_del and subtype_dealloc in a meaningful way with the generator code. At 06:00 PM 6/18/2005 -0400, Phillip J. Eby wrote: >Argh! My email client's shortcut for Send is Ctrl-E, which is the same as >end-of-line in the editor I've been using all day. Anyway, the problem is >that it seems to me as though actually checking for tp_del is too >aggressive (conservative?) for generators, because sometimes a generator >object is finished or un-started, and therefore can't resurrect objects >during close(). However, I don't really know how to implement another >strategy; gcmodule isn't exactly my forte. :) Any input from the GC gurus >would be appreciated. Thanks! > >At 05:56 PM 6/18/2005 -0400, Phillip J. Eby wrote: > >At 05:50 PM 6/18/2005 -0400, Phillip J. Eby wrote: > > >Working on the PEP 342/343 generator enhancements, I've got working > > >send/throw/close() methods, but am not sure how to deal with getting > > >__del__ to invoke close(). Naturally, I can add a "__del__" entry to its > > >methods list easily enough, but the 'has_finalizer()' function in > > >gcmodule.c only checks for a __del__ attribute on instance objects, > and for > > >tp_del on heap types. > > > > > >It looks to me like the correct fix would be to check for tp_del always, > > >not just on heap types. However, when I tried this, I started getting > > >warnings from the tests, saying that 22 uncollectable objects were being > > >created (all generators, in test_generators). > > > > > >It seems that the tests create cycles via globals(), since they define a > > >bunch of generator functions and then call them, saving the generator > > >iterators (or objects that reference them) in global variables > > > > > >after investigating this a bit, it seems to me that either has_finalizer() > > >needs to > > > >Whoops. I hit send by accident. Anyway, the issue seems to mostly be that > >the tests create generator-iterators in global variables. With a bit of > >effort, I've been able to stomp most of the cycles. > >_______________________________________________ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
