A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-April/003444.html below:

[Python-Dev] Crash in new "trashcan" mechanism.

[Python-Dev] Crash in new "trashcan" mechanism.Greg Stein gstein@lyra.org
Wed, 12 Apr 2000 18:25:41 -0700 (PDT)
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
> :-)
> 
> * 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.
> 
> * 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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4