[Python-3000] python-safethread project status
theller at ctypes.org
Tue Mar 18 17:15:03 CET 2008
Adam Olsen schrieb:
> On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
>> <qrczak at knm.org.pl> wrote:
>> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>> > > I've replaced __del__ API (which resurrected objects) with a
>> > > __finalize__/__finalizeattrs__ API (which doesn't). Attributes listed
>> > > in __finalizeattrs__ are proxied into a core object, a finalizer
>> > > thread is given a reference to the core, and when the main object is
>> > > deleted the GC asynchronously notifies the finalizer thread so that it
>> > > can call core.__finalize__(). The net result is an API very similar
>> > > to __del__ (you need to list attributes it might use), but it's now
>> > > impossible for the GC to run arbitrary code (I even enforce this).
>> > Ah! Irrespective of other issues, I like this very much. This design
>> > agrees with my understanding of how finalization should behave, except
>> > that I haven't had details in mind which would fit Python. My abstract
>> > design needs the finalization function to somehow access parts of the
>> > dying object, but not the object itself, and this design shows how to
>> > actually do it in a convenient way.
>> Note that you can use something very much like this right now::
> Yeah. That's missing the finalizer thread, but that could be add.
> Note, you need to use a finalizer thread in order to use locks to
> protect your datastructures. Without it, if you simply preempt the
> current thread like is done today, you can only do operations the
> memory model provides as atomic.
Hm, I could imagine objects that need to be finalized in the thread that created them.
How could that be handled?
More information about the Python-3000