Le conseil de direction de Python prévoit de rendre son “verrou d’interpréteur mondial” facultatif

Le verrou global de l’interpréteur de Python “permet à un seul thread de prendre le contrôle de l’interpréteur Python”, selon le site du tuto Vrai Python. (Ils ajoutent, “cela peut être un goulot d’étranglement des performances dans le code lié au processeur et multithread.”)

Vendredi, le Python Steering Council “a annoncé son intention d’accepter la PEP 703 (Making the Global Interpreter Lock Optional in CPython), avec un support initial pouvant apparaître dans la version 3.13”, rapporte LWN.net.

Depuis l’annonce du conseil d’administration:

Il est clair que le sentiment général est positif, à la fois pour l’idée générale et pour la PEP 703 en particulier. Le Conseil de pilotage est également largement positif sur les deux. Nous avons l’intention d’accepter la PEP 703, bien que nous travaillions toujours sur les détails d’acceptation…

Nos hypothèses de base sont :

– À long terme (probablement plus de 5 ans), la version sans GIL devrait être la seule version. Nous ne voulons pas créer une séparation permanente entre les builds avec et sans GIL (et les modules d’extension).

– Nous voulons être très prudents avec la rétrocompatibilité. Nous ne voulons pas d’une autre situation Python 3, donc toute modification du code tiers nécessaire pour s’adapter aux versions sans GIL devrait fonctionner uniquement dans les versions avec-GIL (bien que la rétrocompatibilité avec les anciennes versions de Python devra encore être abordée). Ce n’est pas Python 4. Nous examinons toujours les exigences que nous voulons imposer sur la compatibilité ABI et d’autres détails pour les deux versions et l’effet sur la rétrocompatibilité.

– Avant de nous engager à passer entièrement à la version sans GIL, nous devons voir le soutien de la communauté pour cela. Nous ne pouvons pas simplement inverser la valeur par défaut et attendre de la communauté qu’elle détermine le travail qu’elle doit faire pour la prendre en charge. Nous, les principaux développeurs, devons acquérir de l’expérience avec le nouveau mode de construction et tout ce qu’il implique. Nous devrons probablement trouver de nouvelles API C et API Python pendant que nous trions la sécurité des threads dans le code existant. Nous devons également faire participer le reste de la communauté Python au fur et à mesure que nous acquérons ces informations et nous assurer que les changements que nous voulons apporter, et les changements que nous voulons qu’ils apportent, sont acceptables.

– Nous voulons pouvoir changer d’avis s’il s’avère, à tout moment avant de faire du no-GIL la valeur par défaut, que cela va être trop perturbateur pour trop peu de gain. Une telle décision pourrait signifier annuler tout le travail, donc jusqu’à ce que nous soyons certains de vouloir faire de no-GIL la valeur par défaut, le code spécifique à no-GIL devrait être quelque peu identifiable.
Le plan actuel est “d’ajouter la version sans GIL en tant que mode de construction expérimental, probablement en 3.13… [A]Après avoir la certitude qu’il existe suffisamment de support communautaire pour rendre l’utilisation de no-GIL viable en production, nous rendons la version no-GIL prise en charge mais pas (encore) par défaut, et définissons une date cible/version Python pour en faire la version par défaut. .. Nous nous attendons à ce que cela prenne au moins un an ou deux, peut-être plus.”

“À long terme, nous voulons que le non-GIL soit la valeur par défaut et supprime tout vestige du GIL (sans rompre inutilement la rétrocompatibilité)… Nous pensons que cela peut prendre jusqu’à cinq ans pour arriver à ce stade.”