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 <[EMAIL PROTECTED]> 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@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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
