Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Release the GIL during evaluation, and decide on free-threaded (cp314t) support

Ouverte
  • Quelque chose ne va pas ?
#45 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
42/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
python, rust
Domaine
backend, ci-cd, performance, testing

Piste de recherche

Commencez par evaluate() et Program.execute(), puis exécutez compile_execute_benchmark.py afin de mesurer le surcoût de detach/attach par rapport au seuil indiqué. Auditez Context, la stdlib Env partagée et le cache par-Context pour vérifier leur sûreté en mode free-threaded, et examinez la matrice CI de maturin-action. Le travail est considéré comme terminé lorsque l’évaluation concurrente est couverte par des tests, que le choix de la libération du GIL a été évalué par benchmark et que des wheels cp314t sont incluses si elles sont prises en charge.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

Problem

evaluate() and Program.execute() hold the GIL for the entire Rust-side evaluation. A Python program that evaluates CEL from several threads therefore serialises on the interpreter even though the work is pure Rust once the context has been converted. This matters for the policy-engine style of use (many rules × many requests) that the README leads with.

Proposal

  1. Release the GIL around program.execute() with py.detach(|| ...) (PyO3 0.29's spelling of allow_threads). The pieces already have the right bounds: cel::Program is a plain AST, cel::Context<'static> is Send + Sync (its Val, Function and VariableResolver traits all require it), and the Python-callback wrappers already do their own Python::attach, so a callback simply re-acquires the GIL when it runs. Conversion of the result back to Python happens after re-attaching.
  2. Measure the fixed cost. Detach/attach is on the order of tens of nanoseconds, but a trivial x + y executes in ~0.15 µs, so unconditional detaching could be a visible relative slowdown for tiny expressions while being a large absolute win for anything heavier or for multi-threaded callers. Options, in order of preference:
    • detach unconditionally if the overhead measures under ~10% on the compile_execute_benchmark.py cases;
    • otherwise detach only when the context has no Python functions and no resolver (that's when the evaluation cannot need the GIL), which is cheap to know from the Context;
    • an explicit execute(ctx, release_gil=...) knob is a last resort.
  3. Free-threaded Python. PyO3 0.29 supports the free-threaded build when the module opts in with #[pymodule(gil_used = false)]. Before doing that, audit: Context mutators are &mut self (PyO3's borrow checker turns concurrent mutation into an error rather than a data race), the shared stdlib Env is a LazyLock, and the per-Context cache proposed in the Context-reuse PR is behind a Mutex. Then add cp314t wheels to the CI matrix (maturin-action needs the interpreter listed explicitly; --find-interpreter won't pick it up).

Non-goals

Context itself is documented as not thread-safe for concurrent mutation; that stays. Concurrent evaluation against a shared Context is already fine and is now pinned by tests.

Langage dominant
Python
Étoiles
43
Forks
4
Merge moyen
12 h 37 min
PR mergées (30 j)
11

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de hardbyte/python-common-expression-language

Toutes les issues de hardbyte/python-common-expression-language

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.