[Python-3000] python-safethread project status

[Adam Olsen]

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::
>
>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635

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.

-- 
Adam Olsen, aka Rhamphoryncus