[Python-3000] python-safethread project status

Adam Olsen rhamph at gmail.com
Mon Mar 17 18:56:36 CET 2008

Guido's asked me to give a quick status report, so here I go..

The critical parts of the design and implementation are basically
done.  I've implemented monitors to contain objects without an
explicit thread-safe API, which then let me remove the GIL.  I've
created a synchronous/asynchronous refcounting scheme that reuses our
existing INCREF/DECREF API, but also minimizes contention when used by
more than one thread.  The net result is that although there's a
significant amount of overhead, I can demonstrate scalability to more
than one thread (I've only been able to test with two cores though.)

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

Missing there is generator cleanup.  I don't allow the GC to run a
generator long enough to raise GeneratorExit, so an alternative will
be needed.

I'm currently working on flushing out the design.  I recently rewrote
and reenabled the tracing GC, next up is the automatic deadlock

As for merging back into CPython, I could build smaller patches, but
the design can't be completely separated.  For example, __finalize__
is called from another thread, so Monitor's @monitormethod should be
applied.  I don't specifically require Monitor, just that the object
(and therefor its methods) be shareable, and Monitor is the easiest
way to provide that.

Adam Olsen, aka Rhamphoryncus

More information about the Python-3000 mailing list