Python Verzending: De GIL optioneel maken
De stuurgroep heeft een grote aankondiging over de toekomst van Python. Ze hebben namelijk besloten om de Global Interpreter Lock (GIL) optioneel te maken in CPython en uiteindelijk de GIL helemaal te verwijderen.
Dit is een enorme beslissing die Python fundamenteel zal veranderen.
Daarom zal ik in dit bericht uitleggen wat de GIL is, wat de voor- en nadelen zijn en wat de toekomst brengt.
De GIL
Laat me de Global Interpreter Lock één woord per keer doorlopen in omgekeerde volgorde, te beginnen met slot en dan tolk en tot slot, wereldwijd.
Een lock is een mechanisme dat slechts één thread tegelijk laat draaien. Dus als een thread het slot in handen krijgt, krijgt het exclusieve toegang tot de Python-interpreter.
Een interpreter is het programma voor het uitvoeren van Python-code.
Het woord "globaal" verwijst hier naar de reikwijdte van het interpreter lock. Omdat het interpreter lock globaal is, garandeert het dat slechts één thread tegelijk Python code uitvoert binnen één proces.
De GIL is dus een mechanisme dat voorkomt dat meerdere threads tegelijkertijd door de interpreter lopen. Maar waarom zou je dat willen?
Voordelen
Het belangrijkste voordeel van de GIL is dat het dingen makkelijker maakt. Het beheren van geheugen is eenvoudiger, het beheren van threads is dus eenvoudiger en het maken van modules is dus eenvoudiger.
Zonder de GIL kun je snel in de problemen komen met multithreading. Als je niet de juiste lokale sloten instelt voor elke thread, kan Python crashen of ander geheugen in de computer beschadigen.
En als je niet multithreading, dan is de GIL super handig, omdat het alles soepel laat lopen.
De GIL houdt de zaken dus eenvoudig en veilig.
Waarom zou je dat dan niet willen?
Nadelen
De afweging hier is gemak voor snelheid.
Door multithreading te voorkomen, maakt de GIL CPython langzamer en minder performant dan sommige andere talen (zoals C++, Go en Rust).
Vooral met de explosie van AI in de afgelopen maanden wordt de GIL steeds meer een probleem om programma's snel en efficiënt uit te voeren.
De toekomst van de GIL
Dus nu de stuurgroep heeft aangekondigd dat ze de Python Verbeteringsvoorstel (PEP) 703, geschreven door Sam GrossWe begeven ons op onbekend terrein.
Ontelbare uitbreidingen zijn geschreven met de GIL in het achterhoofd. Alle standaarden in CPython zijn afhankelijk van de GIL. Iedereen bouwt in CPython met de GIL in het middelpunt van hun programma's (al dan niet opzettelijk).
Daarom maakt de stuurgroep de GIL in eerste instantie optioneel, maar op de lange termijn willen ze de GIL volledig afschaffen.
Zoals ze het in het bericht zeggen: "We willen geen permanente scheiding creëren tussen builds (en uitbreidingsmodules) met en zonder GIL."
Dit zal Python absoluut transformeren en, misschien wel het interessantst, op manieren die nog niemand weet. Brett Cannon, in een enquête aan het kernteam van ontwikkelaarsschreef dat "Python free-threaded maken... veel onbekenden heeft. We weten niet hoeveel code impliciet vertrouwt op de GIL, of thread-onveilig is op subtiele manieren die gemaskeerd worden door de GIL."
De GIL verdwijnt - wat neemt hij mee?
En, nog belangrijker, hoe zal het nieuwe CPython eruit zien?