Free-Threaded Python 3.14 (no-GIL) for Plone: Feasibility Report

[jensens]

TL;DR

Plone cannot currently run on free-threaded Python 3.14. Three core Zope Foundation C extensions fail to even compile, which cascades to block the entire ZODB/Zope stack. Even if those were fixed, lxml would re-enable the GIL anyway.

Report

Date: 2026-02-16
Environment: Plone 6.2.0a2.dev0, Python 3.14.0, coredev (mxdev/mxmake)
Free-threaded Python: cpython-3.14.0+freethreaded via uv python install 3.14t

Executive Summary

Plone cannot currently run on free-threaded Python 3.14t. Three Zope Foundation C extension packages fail to compile, which cascades to block the entire ZODB/Zope persistence and security stack. Even after fixing compilation, lxml (used pervasively in Plone) re-enables the GIL on import, negating any free-threading benefit.

This report categorizes the work needed into phases, from quick mechanical fixes to deep architectural changes.

---

Phase 1: Compilation Fixes (upstream contributions)

These packages fail to build on python3.14t because they directly access PyObject->ob_refcnt, which is no longer a simple struct field in the free-threaded build (uses atomic refcounting instead). The fix is mechanical: replace obj->ob_refcnt with Py_REFCNT(obj) / Py_SET_REFCNT(obj, n).

1.1 persistent (v6.5)

• Repo: https://github.com/zopefoundation/persistent
• File: src/persistent/cPickleCache.c
• Issue: 5 direct ob_refcnt accesses (lines 388, 531, 532, 538, 541)
• Note: PR #214 already fixed cPersistence.c but missed cPickleCache.c
• Fix:
  • Line 388: v->ob_refcnt <= 1 -> Py_REFCNT(v) <= 1
  • Line 531: v->ob_refcnt <= 0 -> Py_REFCNT(v) <= 0
  • Lines 532, 538, 541: v->ob_refcnt -> Py_REFCNT(v) in Py_BuildValue calls
• Effort: Small - single PR
• Unblocks: BTrees, ZODB, zope.container (and everything above)

1.2 ExtensionClass (v6.2)

• Repo: https://github.com/zopefoundation/ExtensionClass
• File: src/ExtensionClass/_ExtensionClass.c
• Issue: 1 direct ob_refcnt access (line 887)
• Note: PR #81 added "preliminary 3.14 support" but did not address the free-threaded build
• Fix:
  • Line 887: callable->ob_refcnt == 1 -> Py_REFCNT(callable) == 1
• Effort: Trivial - single line
• Unblocks: Acquisition, AccessControl, Persistence (and everything above)

1.3 zodbpickle (v4.3)

• Repo: https://github.com/zopefoundation/zodbpickle
• File: src/zodbpickle/_pickle_33.c
• Issues:
  1. ob_refcnt direct access (1 occurrence)
  2. PyFloat_Pack8 / PyFloat_Unpack8 type signature changed from unsigned char * to char * in Python 3.14
• Note: PR #104 added 3.14 support but did not cover the free-threaded build
• Fix: Update signatures and replace ob_refcnt access
• Effort: Small - single PR
• Unblocks: ZODB

Cascade: Packages unblocked by Phase 1

Once the above three are fixed, these packages (which failed only due to transitive dependencies) should install:

Package	Version	Blocked by
BTrees	6.3	persistent
Acquisition	6.2	ExtensionClass
AccessControl	7.3	ExtensionClass
Persistence	5.4	ExtensionClass
ZODB	6.1	persistent, BTrees
zope.container	7.2	persistent

---

Phase 2: Packages That Already Work

These were verified to compile and install on python3.14t:

Package	Version	Notes
zope.interface	8.2	Builds from source, OK
zope.proxy	7.1	Builds from source, OK
zope.security	8.3	Builds from source, OK
zope.hookable	8.2	Builds from source, OK
zope.i18nmessageid	8.2	Builds from source, OK
Pillow	12.1.1	cp314t wheels on PyPI, CI-tested, supported since 11.0.0
cffi	2.0.0	Full free-threaded support
cryptography	46.0.5	Full free-threaded support (Rust/PyO3)
PyYAML	6.0.3	cp314t wheels on PyPI (not CI-tested)
wrapt	2.1.1	Full free-threaded support since 1.17.0
MarkupSafe	3.0.3	Builds from source, OK
Chameleon	4.6.0	Pure Python
RestrictedPython	8.1	Pure Python

---

Phase 3: lxml - The Fundamental Blocker

• Installed: 5.4.0 / Latest: 6.0.2
• Upstream bug: https://bugs.launchpad.net/lxml/+bug/2111289
• Status: cp314t wheels exist on PyPI but they force-enable the GIL on import

The Problem

lxml's Cython/C code fundamentally relies on the GIL for thread safety. From the maintainer (Stefan Behnel):

"lxml makes tight use of the GIL for performance reasons, and the _elementFactory function is central, critical and carefully crafted to benefit from the GIL without requiring additional locking."

The test suite segfaults under free-threaded Python in multi-threaded tests (test_concurrent_class_lookup, test_concurrent_proxies).

Impact on Plone

lxml is used everywhere in Plone:

• Chameleon TAL template compilation (HTML/XML parsing)
• Products.PortalTransforms (content transformations)
• plone.outputfilters (output processing)
• diazo / plone.app.theming (XSLT theme transforms)
• plone.namedfile (SVG handling)
• Content import/export

Even if all Zope packages were fixed, importing lxml re-enables the GIL, negating all free-threading benefits.

Action

• Monitor lxml's Launchpad bug and GitHub for progress
• No Plone-side workaround exists - lxml is deeply embedded in the stack
• Consider contributing to lxml's free-threading effort if resources allow

---

Phase 4: Runtime Thread-Safety (Long-Term)

Even after compilation fixes (Phase 1) and lxml support (Phase 3), the Zope/ZODB stack was designed with the GIL as an implicit lock. True free-threaded operation requires thread-safety audits and fixes across the stack.

4.1 ZODB / persistent

• Pickle cache (cPickleCache.c): Ghost/active object state transitions are not thread-safe without the GIL
• Connection management: Connection._registered_objects, _added, _modified are plain dicts/lists
• Transaction machinery: Global transaction manager state
• BTrees: Not safe for concurrent writes; concurrent reads may also be unsafe without GIL

4.2 Acquisition

• Implicit acquisition wrapping creates complex object graphs at runtime
• aq_acquire, aq_parent traversal assumes stable object references
• Would need locking or copy-on-write semantics

4.3 AccessControl

• Security checks use global/thread-local state (SecurityManager)
• Permission caching assumes GIL protection
• guarded_import already has a known race condition (see zopefoundation/AccessControl PR "Prevent race condition in guarded_import")

4.4 Chameleon (pure Python concerns)

• Template compilation cache (_template_cache) is a plain dict
• Concurrent compilation of the same template could cause issues
• Would need threading.Lock around cache access

4.5 Zope Foundation's Position

In zopefoundation/meta#240 (May 2024), the maintainer stated:

"I have no idea how a free-threaded version would interact with any of our packages."

The free-threaded build is currently skipped in CI for Zope Foundation packages. There is no active initiative to support free-threaded Python.

---

Phase 5: Test Infrastructure

• grpcio (used by robotframework-browser via plone.app.robotframework): No cp314t wheels, no free-threaded support. Robot/acceptance tests won't run.
• Action: Not a runtime blocker. Robot tests would need to wait for grpcio free-threaded support or use an alternative test approach.

---

Summary: Action Items by Priority

Immediate / Low-Effort (contribute upstream)

#	Action	Target Repo	Effort
1	Fix ob_refcnt in cPickleCache.c	zopefoundation/persistent	~1h
2	Fix ob_refcnt in _ExtensionClass.c	zopefoundation/ExtensionClass	~15min
3	Fix build issues in _pickle_33.c	zopefoundation/zodbpickle	~2h

These are good contributions regardless of free-threading - they fix forward compatibility with CPython internal API changes.

Medium-Term / Monitor

#	Action	Who
4	Monitor lxml free-threading progress	lxml maintainers
5	Request Zope Foundation CI for free-threaded builds	zopefoundation/meta
6	Audit Chameleon template cache for thread safety	Chameleon maintainers

Long-Term / Major Effort

#	Action	Scope
7	Thread-safety audit of ZODB connection/cache/transaction	Months of work
8	Thread-safety audit of BTrees for concurrent access	Significant
9	Thread-safety audit of Acquisition wrapping	Significant
10	Thread-safety audit of AccessControl security checks	Significant

---

Appendix: Test Environment Details

Python (standard):  3.14.0 (main, Oct 14 2025) [Clang 20.1.4]
Python (free-threaded): 3.14.0 free-threading build (main, Oct 28 2025) [Clang 20.1.4]
Plone: 6.2.0a2.dev0
Total packages: 350
C extensions: ~70 .so files
Build system: mxdev + mxmake + uv

[jensens]

I looked into persistent and now I have a PR zopefoundation/persistent#230

[jensens]

And on the way I found Zope's meta does not support free-threaed Python as well, which can be solved by a simple fix: zopefoundation/meta#389

[jensens]

lxml and Free-Threaded Python (3.14t): In-Depth Analysis

Date: 2026-02-16
Repository analyzed: https://github.com/lxml/lxml (commit 7c622007, master + ft_python branch)
Upstream bug: https://bugs.launchpad.net/lxml/+bug/2111289
Context: Phase 3/4 of Plone free-threaded Python feasibility (Products.CMFPlone#4277)

---

1. Executive Summary

lxml cannot safely run without the GIL on master today. Current cp314t wheels on PyPI
force-enable the GIL on import, negating free-threading benefits. An active development
branch (ft_python, ~450 commits since May 2025) is adding document-level read-write
locking, atomic proxy management, and a custom RWLock implementation. This work is
substantial but incomplete -- deadlocks and edge cases remain. There is no release date.

---

2. The Core Problem

2.1 Why lxml Depends on the GIL

lxml's architecture assumes the GIL serializes all access to three critical shared
resources:

1. Proxy mapping (c_node._private): Every libxml2 C node stores a raw void*
   pointer back to its Python _Element wrapper. Reading/writing this pointer is
   unprotected.

2. Element factory (_elementFactory): Creates Python Element wrappers on demand.
   Contains intentional re-entry checks that only work because the GIL prevents true
   concurrent execution within a single check-then-act sequence.

3. Document tree: libxml2 xmlDoc and xmlNode structures are freely mutated
   (insert, remove, move, copy) without any locking.

From the maintainer (Stefan Behnel):

"lxml makes tight use of the GIL for performance reasons, and the _elementFactory
function is central, critical and carefully crafted to benefit from the GIL without
requiring additional locking."

2.2 Observable Failures

Under free-threaded Python (without GIL enforcement), lxml's test suite segfaults
in multi-threaded tests:

• test_concurrent_proxies -- 10 threads each do 10,000 iterations of el = root[i % N]; del el
• test_concurrent_class_lookup -- Same pattern but with a custom element class lookup that
  forces thread interleaving
• test_concurrent_attribute_names_in_dicts -- Concurrent attribute creation across shared dict names

---

3. Detailed Analysis of Unsafe Code Paths

3.1 Proxy Registration/Lookup (proxy.pxi)

File: src/lxml/proxy.pxi, lines 9-49

cdef inline _Element getProxy(xmlNode* c_node):
    if c_node is not NULL and c_node._private is not NULL:
        return <_Element>c_node._private      # UNSAFE: raw cast of void*
    return None

cdef inline int _registerProxy(_Element proxy, _Document doc,
                               xmlNode* c_node) except -1:
    assert not hasProxy(c_node), "double registering proxy!"
    proxy._doc = doc
    proxy._c_node = c_node
    c_node._private = <void*>proxy            # UNSAFE: unprotected write

cdef inline int _unregisterProxy(_Element proxy) except -1:
    cdef xmlNode* c_node = proxy._c_node
    c_node._private = NULL                     # UNSAFE: unprotected write

Race scenario (without GIL):

• Thread A: reads c_node._private, gets a valid pointer
• Thread B: runs _unregisterProxy, sets c_node._private = NULL, decrefs the Element
• Thread A: casts the now-dangling pointer to _Element -> use-after-free / segfault

3.2 Element Factory (etree.pyx:1754-1779 on master)

cdef _Element _elementFactory(_Document doc, xmlNode* c_node):
    result = getProxy(c_node)
    if result is not None:
        return result                         # Fast path: reuse

    # TOCTOU window #1: class lookup calls Python code
    element_class = LOOKUP_ELEMENT_CLASS(ELEMENT_CLASS_LOOKUP_STATE, doc, c_node)

    if hasProxy(c_node):                      # Re-entry check
        return getProxy(c_node)

    result = element_class.__new__(element_class)

    # TOCTOU window #2: __new__ calls Python code
    if hasProxy(c_node):                      # Second re-entry check
        result._c_node = NULL
        return getProxy(c_node)

    _registerProxy(result, doc, c_node)       # Winner registers

The double-checking pattern works under GIL because Python callbacks can trigger
re-entry (via GIL release+reacquire during C calls), but NOT true parallelism.
Without the GIL, two threads can race through the entire function simultaneously
and both call _registerProxy -> double registration assert or corruption.

3.3 Element Deallocation (proxy.pxi:133-193)

cdef int attemptDeallocation(xmlNode* c_node) noexcept:
    c_top = getDeallocationTop(c_node)
    if c_top is not NULL:
        _removeText(c_top.next)
        tree.xmlFreeNode(c_top)               # UNSAFE: frees C memory

cdef xmlNode* getDeallocationTop(xmlNode* c_node) noexcept:
    if hasProxy(c_node):                      # Check proxy exists
        return NULL
    while c_node.parent is not NULL:
        c_node = c_node.parent
        if hasProxy(c_node):                  # Walk up, check proxy
            return NULL
    if not canDeallocateChildNodes(c_node):   # Walk down, check children
        return NULL

Race scenario: Thread A traverses the tree checking for proxies. Thread B
concurrently creates a proxy for one of those nodes. Thread A concludes the tree
is safe to free, calls xmlFreeNode -> Thread B now holds a proxy pointing to
freed memory.

3.4 Global Mutable State

Location	State	Risk
classlookup.pxi:537-538	LOOKUP_ELEMENT_CLASS, ELEMENT_CLASS_LOOKUP_STATE	Global function pointer + state object, set via set_element_class_lookup()
parser.pxi	__GLOBAL_PARSER_CONTEXT	Global parser context with thread-local dict lookup
nsclasses.pxi	_DEFAULT_NAMESPACE_PREFIXES	Global dict modified by register_namespace()
etree.pyx	Default parser instances	Shared across threads

---

4. The ft_python Branch: What's Being Done

The ft_python branch (diverged ~May 2025, ~450 commits) implements a comprehensive
locking strategy. Key changes:

4.1 Document-Level Read-Write Lock

A new RWLock class (rwlock.pxi, 439 lines) provides writer-preferring read-write
locking using:

• C11 atomics (preferred) or Python pyatomics.h for reader counting
• PyMutex for blocking (Cython 3.2's cython.pymutex)
• Fallback to CPython critical sections on platforms without atomics

The lock is embedded in every _Document:

cdef public class _Document:
    cdef RWLock _lock
    cdef cython.pymutex _proxy_lock    # Short-lived lock for proxy link changes

4.2 Locking Granularity

Every public _Element method now acquires the document lock:

Operation	Lock Type	Example
__getitem__, get(), text, tag	doc.lock_read()	Read-only tree traversal
append(), remove(), set(), __setitem__	doc.lock_write()	Tree mutation
__deepcopy__, tostring()	doc.lock_read()	Serialization
Cross-document moves	doc.lock_write_with(other_doc)	Deterministic double-lock to avoid deadlocks
Proxy register/unregister	doc.lock_proxies() (pymutex)	Short critical section

4.3 Proxy Safety with TryIncRef

The proxy mechanism uses CPython 3.14's new PyUnstable_TryIncRef API:

# ft_python: proxy.pxi
cdef inline _Element getProxy(xmlNode* c_node):
    if c_node is NULL or not hasProxy(c_node):
        return None
    if not python.HAS_TryIncRef:
        return <_Element> c_node._private
    if not python.PyUnstable_TryIncRef(<PyObject*> c_node._private):
        c_node._private = NULL       # Object was already deallocated
        return None
    element = <_Element> c_node._private
    python.Py_DECREF(element)        # Correct double incref
    return element

This prevents the use-after-free race: if the Element object's refcount has already
reached zero (being finalized by another thread), TryIncRef returns 0 and the proxy
is safely invalidated.

4.4 Element Finalization Changed to __del__

The _Element.__dealloc__ (tp_dealloc, C-level) is replaced by __del__ (tp_finalize,
Python-level), which can safely acquire locks:

def __del__(self):
    c_node = self._c_node
    if c_node is NULL:
        return
    doc = self._doc
    if doc is not None:
        doc.lock_proxies()
    try:
        c_node = self._c_node
        if c_node is NULL:
            return
        _unregisterProxy(self)
        c_top = getDeallocationTop(c_node)
    finally:
        if doc is not None:
            doc.unlock_proxies()
    if c_top is not NULL:
        freeSubtree(c_top)

4.5 Element Factory with Proxy Lock

cdef _Element _elementFactory(_Document doc, xmlNode* c_node):
    if c_node is NULL:
        return None

    if hasProxy(c_node):
        doc.lock_proxies()
        try:
            result = getProxy(c_node)
            if result is not None:
                return result
        finally:
            doc.unlock_proxies()

    element_class = LOOKUP_ELEMENT_CLASS(...)

    if hasProxy(c_node):
        doc.lock_proxies()
        try:
            result = getProxy(c_node)
            if result is not None:
                return result
        finally:
            doc.unlock_proxies()

    result = element_class.__new__(element_class)

    doc.lock_proxies()
    try:
        if hasProxy(c_node):
            proxy = getProxy(c_node)
            if proxy is not None:
                result._c_node = NULL
                return proxy
        _registerProxy(result, doc, c_node)
    finally:
        doc.unlock_proxies()

4.6 Parser/Resolver Thread Safety

The input resolver (_local_resolver) is rewritten to use libxml2 2.14's new
per-context resource loader API (xmlResourceLoader) instead of the global
xmlSetExternalEntityLoader. This eliminates a major source of global mutable state.

4.7 Build Configuration

# setupinfo.py
if sys.version_info >= (3, 14):
    cythonize_directives['freethreading_compatible'] = True

This tells Cython to emit Py_MOD_GIL_NOT_USED in the module definition, so
Python 3.14t won't re-enable the GIL on import.

On Python 3.13t, this is explicitly disabled (crashes).

---

5. Remaining Challenges

5.1 Known Deadlock Risk

The rwlock implementation is complex (writer-preferring with atomic reader counting).
Commit ada98d0d (Nov 2025) adds "a trace helper to log the thread interactions
before deadlocks", indicating this is an active area of debugging. The lock has
performance counters (LXML_LOCK_PERFORMANCE=1) to diagnose contention.

5.2 Scope of Locking Needed

The diff between master and ft_python is massive: 4,477 insertions, 1,311 deletions
across 57 files. Every .pxi module needs review:

Module	Lock calls added	Complexity
etree.pyx	~100+ lock/unlock pairs	Very high (1,447 lines changed)
objectify.pyx	~50+ lock/unlock pairs	High (435 lines changed)
serializer.pxi	Moderate	Medium
xpath.pxi	Read/write lock for eval	Medium
xslt.pxi	Read/write lock for apply	Medium
parser.pxi	Major resolver rewrite	High
apihelpers.pxi	Many utility functions	High
readonlytree.pxi	Extensive locking	High (386 lines changed)
cleanup.pxi	Tree cleanup locking	Medium

5.3 Performance Impact

Every element access now requires lock acquisition/release. The branch adds benchmarks
(benchmark/) comparing:

• master vs ft_python on regular Python (lock overhead)
• Regular Python vs FT-Python (parallelism gains vs lock contention)

The RWLock uses atomics for the fast path (no writer waiting -> atomic increment only),
but contended writes will serialize on PyMutex.

5.4 libxml2 Thread Safety

libxml2 itself was designed for "one thread per document" usage. The lxml locking
strategy of one RWLock per document aligns with this model. However:

• xmlDict (string interning dictionary): Per-document, but shared when documents
  are created from the same parser. Thread-safe via xmlDictOwns/xmlDictLookup but
  performance may suffer under contention.
• Global state in libxml2 (error handlers, memory allocators): Set once at init
  time. The ft_python branch rewrites the resolver to use per-context callbacks where
  libxml2 2.14+ supports it.

5.5 Cython 3.2 Dependency

The ft_python branch requires Cython 3.2 for:

• cython.pymutex (maps to CPython's PyMutex)
• cython.critical_section (maps to Py_BEGIN_CRITICAL_SECTION)
• freethreading_compatible directive

This is a hard requirement. The master branch uses Cython 3.0.x.

---

6. Current Status and Timeline

Milestone	Date	Status
Bug reported (PyCon sprints)	May 2025	Done
ft_python branch created	~June 2025	Done
freethreading_compatible directive added	June 2025	Done
TryIncRef proxy safety	Aug 2025	Done
RWLock implementation	~Aug-Nov 2025	Done
Benchmark infrastructure	Dec 2025-Feb 2026	Done
cp314t wheels on PyPI (GIL still enabled)	Nov 2025	Done
Resolver rewrite (libxml2 2.14 API)	Dec 2025	Done
_freethreading_enabled detection	Dec 2025	Done
Deadlock debugging ongoing	Feb 2026	In Progress
Merge to master	TBD	Not scheduled
Release with FT support	TBD	Not scheduled

The ft_python branch is NOT merged to master. It is actively developed but not
yet considered stable enough for release.

---

7. Impact Assessment for Plone

7.1 Why lxml Blocks Everything

lxml is used pervasively in Plone:

• Chameleon TAL templates: HTML/XML parsing for every page render
• diazo / plone.app.theming: XSLT transformations on every response
• plone.outputfilters: Output processing pipeline
• Products.PortalTransforms: Content type conversion
• plone.namedfile: SVG handling
• Content import/export: GenericSetup profiles

Even if all Zope Foundation C extensions (persistent, ExtensionClass, zodbpickle) were
fixed for free-threaded Python, importing lxml re-enables the GIL, negating all
free-threading benefits for the entire process.

7.2 Workaround Options

Option	Feasibility	Notes
Wait for lxml ft_python merge	Medium-term	No timeline, complex ongoing work
Replace lxml with stdlib xml.etree	Not feasible	Missing XSLT, XPath, schema validation, HTML parsing
Use lxml with GIL re-enabled	Works today	No free-threading benefit, but no breakage
Isolate lxml in subprocesses	Very complex	Would require rewriting Plone's entire rendering pipeline

7.3 What Plone Could Do

1. Test with ft_python branch wheels: Build lxml from the ft_python branch and run
   Plone's test suite to find lxml-specific issues early
2. Report issues upstream: If ft_python crashes with Plone's usage patterns, report
   them to lxml to help stabilize the branch
3. Avoid set_element_class_lookup() at runtime: Ensure this global-state-modifying
   call only happens at import time, not per-request
4. Monitor progress: Watch the ft_python branch and lxml releases for FT support

---

8. Conclusions

1. lxml's GIL dependency is architectural, not a simple compilation fix. The proxy
   system, element factory, and deallocation logic all rely on the GIL for correctness.

2. Active work is underway on the ft_python branch with ~450 commits, a custom
   RWLock, document-level locking, and CPython 3.14 TryIncRef integration. This is
   serious, expert-level work by the maintainer.

3. The scope is enormous: 57 files changed, 4,477 lines added. Every public API
   method needs lock/unlock calls. Deadlocks remain an active debugging concern.

4. No release timeline exists. The branch has not been merged to master. lxml 6.x
   wheels for cp314t still force-enable the GIL.

5. For Plone, lxml is the fundamental blocker for free-threaded Python. No
   workaround exists that doesn't involve either waiting for lxml or removing lxml
   from the stack (not feasible).

6. Cython 3.2 and libxml2 2.14 are hard dependencies for the free-threading work,
   adding to the complexity of the eventual release.

[jensens]

Progress Update: Phase 1 C Extension Fixes

Done

• persistent: PR Use CPython API macros for ob_refcnt and ob_type access (free-threading support) zopefoundation/persistent#230 — fixes ob_refcnt direct access in cPickleCache.c, adds CI for 3.14t, includes threading test improvements. CI green.
• ExtensionClass: PR Fix free-threaded Python 3.14t compilation and thread safety zopefoundation/ExtensionClass#89 — fixes ob_refcnt + guards thread-unsafe im_self mutation optimization with #ifndef Py_GIL_DISABLED. CI green.
• zodbpickle: C fixes done (ob_refcnt → Py_REFCNT, ob_type → Py_TYPE in _pickle_33.c), builds and tests pass on both 3.14 and 3.14t. PR pending.

Blocker: zope.interface

While testing zodbpickle on 3.14t, the GIL gets re-enabled on import:

The global interpreter lock (GIL) has been enabled to load module
'zope.interface._zope_interface_coptimizations'

zope.interface's C extension does not declare Py_mod_gil_not_used, so Python re-enables the GIL for the entire process. This means all the above free-threading fixes are effectively negated at runtime — zope.interface loads before persistent, ZODB, and everything else in the stack.

Existing upstream issue: zopefoundation/zope.interface#332 (open since Feb 2025, no work done yet).

zope.interface is the foundational blocker for free-threaded Python in the Zope/Plone stack. Without it declaring free-threading support, the GIL stays on for any process that imports it — which is every Zope/Plone process.

Next step: investigate what's needed to make zope.interface's C extensions free-threading compatible.

[jensens]

Progress Update: zope.interface — the foundational blocker is addressed

All Phase 1 PRs now submitted

Package	Issue	PR	Status
persistent	#229	#230	CI green
ExtensionClass	#88	#89	CI green
zodbpickle	#106	#107	Draft, wait for zope.interface
zope.interface	#332	#352	CI green

zope.interface details

zope.interface is the foundational blocker — without it declaring free-threading support, the GIL is re-enabled for the entire process on import, negating all other free-threading work.

The fix in PR #352 goes beyond the mechanical ob_refcnt/ob_type fixes needed for the other packages:

1. Py_mod_gil_not_used declaration in module slots — prevents GIL re-enable on import
2. PyDict_GetItemRef() strong references replacing PyDict_GetItem() borrowed references in all cache lookup functions — prevents use-after-free when another thread clears a cache between dict lookup return and Py_INCREF(). Includes a zero-overhead polyfill for Python < 3.13.
3. Py_TYPE() macro instead of direct ob_type struct access

The good news: zope.interface already had multi-phase module init, per-module state, and heap types (Python >= 3.11) from the earlier PR #301 refactoring. This made the free-threading fix feasible without a massive rewrite.

Benchmarked on Python 3.14: zero performance regression on cached adapter lookups (~115ns/call → ~109ns/call). All 1358 tests pass on both Python 3.14 and 3.14t.

[tisto]

@jensens thank you for working on this Jens!

[jensens]

Status Update: All Phase 1 PRs Merged (as of 2026-03-20)

All free-threading compilation fix PRs in zopefoundation repos have been merged. Here's the complete status:

Phase 1: C Extension Fixes — All Merged

Package	PR	Merged	Description
zope.interface	#352	2026-02-17	Free-threaded Python 3.14t C extension support (Py_mod_gil_not_used, PyDict_GetItemRef, Py_TYPE)
persistent	#230	2026-03-11	ob_refcnt/ob_type → CPython API macros in cPickleCache.c
ExtensionClass	#89	2026-03-12	ob_refcnt fix + #ifndef Py_GIL_DISABLED guard for thread-unsafe optimization
zodbpickle	#107	2026-03-17	ob_refcnt/ob_type → API macros in _pickle_33.c

CI Infrastructure — Merged

Repo	PR	Merged	Description
meta	#389	2026-02-19	Add with-free-threaded-python option for CI matrix
meta	#397	2026-03-10	Exclude tests.yml from check-python-versions with free-threaded Python
meta	#395	2026-03-11	Add publish-free-threaded-wheels option for wheel publishing
zope.interface	#356	2026-03-11	Enable publishing free-threaded Python wheels

Additional Improvements

Repo	PR	Merged	Description
zope.interface	#353	2026-02-27	Optimize C extension hot paths

Pending: No New PyPI Releases Yet

None of the above packages have published new PyPI releases including the free-threading fixes:

• persistent: latest is 6.5 (pre-merge)
• ExtensionClass: latest is 6.2 (pre-merge)
• zodbpickle: latest is 4.3 (pre-merge)
• zope.interface: latest is 8.2 (pre-merge)

The fixes are in the main branches but require new releases to be available via pip install. Until then, free-threading support requires installing from source/git.

Remaining Blockers (unchanged)

• lxml: Still the fundamental blocker. The ft_python branch is under active development but not merged to master, no release timeline.
• Phase 4 (runtime thread-safety): ZODB, Acquisition, AccessControl, Chameleon — no new activity.