Greg Stein wrote:
On Thu, 13 Apr 2000, Mark Hammond wrote:
... I see these possible solutions:
* The trash mechanism is changed to keep a list of (address, deallocator) pairs. This is a "cleaner" solution, as the list is not considered holding PyObjects as such, just blocks of memory to be freed with a custom allocator. Thus, we never end up in a position where a Python objects are resurrected - we just defer the actual memory deallocation, rather than attempting a delayed object destruction. This may not be as trivial to implement as to describe :-)
This one sounds quite hard to implement.
* Debug builds disable the trash mechanism. Not desired as the basic behaviour of the interpreter will change, making bug tracking with debug builds difficult! If we went this way, I would (try to :-) insist that the Windows debug builds dropped Py_DEBUG, as I really want to avoid the scenario that switching to a debug build changes the behaviour to this extent.
I vote for this one at the moment.
* Perform further hacks, so that Py_ForgetReference() gracefully handles NULL linked-list elements etc.
Any thoughts?
Option 4: lose the trashcan mechanism. I don't think the free-threading issue was ever resolved.
Option 5: Forget about free threading, change trashcan in a way that it doesn't change the order of destruction, doesn't need memory at all, and therefore does not change anything if it is disabled in debug mode. cheers - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com