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

Idea: acquire the GIL in all API functions

Ouverte
  • Quelque chose ne va pas ?
#697 2 commentaires 1 réaction 1 personne assignée Voir sur GitHub

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

@cjdoris y travaille déjà.

Depuis le 16/10/2025.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

The Problem

Currently none of our API touches the GIL, except for the explicit GIL handling in PythonCall.GIL. This means that users must ensure that all API functions are only called on the thread holding the GIL, which is normally the main thread.

However this makes it hard to do anything in a multithreaded setting. You can try to use GIL.@lock etc to ensure a thread holds the GIL but this is fiddly to get right. Especially as Julia can migrate tasks between threads, so the threadid may change between acquiring and releasing the lock.

Sometimes you don't know that your code will be run in a multithreaded setting. An annoying case of this is that on Julia 1.12+, it will by default launch 1 interactive and 1 default thread. The REPL runs in the interactive thread but auto-completions runs in the default thread. This means that as soon as you type julia> np. it will crash because propertynames(::Py) is called on the wrong thread.

The Proposal

Have all of the API functions explicitly acquire the GIL and release it again when they are done. This will require releasing the GIL at the end of __init__.

This will mean you can call any PythonCall API function from any thread and things should "just work", with the caveat that the GIL will force any parallel Python calls to be performed serially.

Considerations

  • How much of a performance impact will this have? Hopefully PyGILState_Ensure is fast if the GIL is already held, so that any larger blocks of code inside a GIL.@lock are OK.
  • Can we really ensure that the threadid doesn't change between acquiring and releasing the GIL? We can at least record the threadid when we lock and check it when we unlock, or before any other calls into CPython. We should have the lock as tight as possible around the corresponding CPython function.
  • We should introduce a re-entrant lock that works in tandem with the GIL, otherwise we will quickly deadlock a thread. This will have the downside that if the GIL is released Python-side, this other lock will not be released, so PythonCall functions will stay waiting.
  • We'll need to make everything else thread-safe too - e.g. all the globals should have locks.
  • We can make unsafe versions of the API functions which don't handle the GIL, which can be used to compose higher-level functions which do handle the GIL.
  • In particular @py could acquire the GIL once and use these unsafe functions.
  • Consider changing GIL.@unlock to not do anything if the GIL is already unlocked. Currently it assumes the GIL is held.
  • Is this breaking? Should it wait for v1?
Langage dominant
Julia
Étoiles
1.1k
Forks
89
Merge moyen
23 h 52 min
PR mergées (30 j)
4

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

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 JuliaPy/PythonCall.jl

Toutes les issues de JuliaPy/PythonCall.jl

Issues similaires

Plus d'issues Julia

Recevez les nouvelles issues par e-mail

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