Author: Armin Rigo <ar...@tunes.org> Branch: extradoc Changeset: r5610:a8a9dcfcf523 Date: 2016-02-25 16:18 +0100 http://bitbucket.org/pypy/extradoc/changeset/a8a9dcfcf523/
Log: updates diff --git a/blog/draft/cpyext-gcsupport.rst b/blog/draft/cpyext-gcsupport.rst --- a/blog/draft/cpyext-gcsupport.rst +++ b/blog/draft/cpyext-gcsupport.rst @@ -1,23 +1,50 @@ CAPI Support update =================== -I have merged a rewrite of the interaction between c-API c-level objects and -interpreter level objects. Each refcounted c-level object is now reflected in -an interpreter level object, and the garbage collector can release the object -pair only if the refcount is 0 and the interpreter level object is not longer -referenced. +As you know, PyPy can emulate the CPython C API to some extent. It is +done by passing around ``PyObject *`` pointers. Inside PyPy, the +objects don't have the same ``PyObject *`` structure at all; and +additionally their memory address can change. PyPy handles the +difference by maintaining two sets of objects. More precisely, starting +from a PyPy object, it can allocate on demand a ``PyObject`` structure +and fill it with information that points back to the original PyPy +objects; and conversely, starting from a C-level object, it can allocate +a PyPy-level object and fill it with information in the opposite +direction. -The rewrite significantly simplifies our previous code, and should make using -the c-API less slow (it is still slower than using pure python though). -XXX citations needed ... +I have merged a rewrite of the interaction between C-API C-level objects +and PyPy's interpreter level objects. This is mostly a simplification +based on a small hack in our garbage collector. This hack makes the +garbage collector aware of the reference-counted ``PyObject`` +structures. When it considers a pair consisting of a PyPy object and a +``PyObject``, it will always free either none or both of them at the +same time. They both stay alive if *either* there is a regular GC +reference to the PyPy object, *or* the reference counter in the +``PyObject`` is bigger than zero. -The good news is that now PyPy can support the upstream `lxml`_ package, which is -is one of the most popular packages on PyPI (specifically version X.X.X with old -PyPy specific hacks removed). We do recommend using the `cffi lxml`_ alternative, -since it will be faster on PyPy. +This gives a more stable result. Previously, a PyPy object might grow a +corresponding ``PyObject``, loose it (when its reference counter goes to +zero), and later have another corresponding ``PyObject`` re-created at a +different address. Now, once a link is created, it remains alive until +both objects die. -We are actively working on extending our c-API support, and hope to soon merge -a branch to support more of the c-API functions. Please try it out and let us -know how it works for you. +The rewrite significantly simplifies our previous code (which used to be +based on at least 4 different dictionaries), and should make using the +C-API less slow (it is still slower than using pure python or cffi). + +So, the good news is that now PyPy actually supports the upstream +`lxml`_ package---which is is one of the most popular packages on PyPI. +(Specifically, you need version 3.5.0 with +https://github.com/lxml/lxml/pull/187 to remove old PyPy-specific hacks +that were not really working.) At this point, we no longer recommend +using the `cffi lxml`_ alternative: although it may still be faster, it +might be incomplete and old. + +We are actively working on extending our C-API support, and hope to soon +merge a branch to support more of the C-API functions (some numpy news +coming!). Please `try it out`_ and let us know how it works for you. + +_`lxml`: https://github.com/lxml/lxml +_`try it out`: http://buildbot.pypy.org/nightly/trunk/ Armin Rigo and the PyPy team _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
