[Python-3000] python-safethread project status

[Adam Olsen]

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
detection/breaking.

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