[Python-3000] python-safethread project status

[Guido van Rossum]

Thanks! Would you care to give us a hint on how a typical
multi-threaded application would be written using this approach? How
much pre-existing code would break do you expect?

On Mon, Mar 17, 2008 at 12:56 PM, Adam Olsen <rhamph at gmail.com> wrote:
> 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
>  _______________________________________________
>  Python-3000 mailing list
>  Python-3000 at python.org
>  http://mail.python.org/mailman/listinfo/python-3000
>  Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)