On Wed, 28 Jul 2010 11:56:16 +0100 Michael Foord <fuzzy...@voidspace.org.uk> wrote: > > This is the kind of approach that seems to hold the most promise of > > removing the GIL without incurring the single-threaded performance hit > > that has been the achilles heel of previous attempts at creating a > > free-threaded CPython implementation. With first IronClad and now PyPy > > blazing the trail in interfacing a garbage collected Python > > implementation with deterministic refcounting for C extension modules, > > it seems plausible that this kind of approach may eventually prove > > acceptable. > > > > Furthermore, the with statement now provides a superior alternative to > > application level tricks that previously relied on deterministic > > refcounting. > > > > While multi-threading does break down beyond a certain number of > > cores, it *is* possible to do safely (particularly using queues to > > pass references around) and can avoid plenty of serialisation overhead > > when dealing with sizable data structures. > > > > Breaking binary compatibility with C extensions would be "difficult" > once PEP 384 (stable binary ABI) has gone into effect.
"Stable" doesn't mean eternal. At worse, we could call the result Python 4.0. It should be noted, though, that a full GC can be detrimental to real-time applications. Kristján has already explained how some of his software disabled the cyclic GC, and took care of breaking cycles manually instead. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
