[Python-3000] python-safethread project status

[Thomas Heller]

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::
>>
>>     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.
> 

Hm, I could imagine objects that need to be finalized in the thread that created them.
How could that be handled?

Thomas