Kannst du erklären, was das GIL ist und was es tatsächlich schützt?

Das Global Interpreter Lock ist ein Mutex in CPython, der immer nur einen Thread Python-Bytecode ausführen lässt und damit den Interpreter-Zustand schützt, etwa Referenzzähler und interne Objektstrukturen. Das heißt, Threads bringen dir bei CPU-lastigem Python-Code keine parallele Beschleunigung, helfen aber weiterhin bei I/O, weil das Lock während blockierender Aufrufe und in C-Extensions freigegeben wird.

Das GIL ist ein einzelnes Lock in CPython, das garantiert, dass zu jedem Zeitpunkt nur ein Thread Python-Bytecode ausführt. Es existiert, weil Reference Counting nicht thread-safe ist und ein Lock pro Objekt für den Single-Threaded-Fall, in dem der meiste Code lebt, langsamer wäre. Praktisch heißt das: Threads sind großartig zum Warten und nutzlos zum Rechnen. In einer Datenpipeline, an der ich gearbeitet habe, hatten wir einen Schritt, der etwa achthundert URLs abgeholt hat, und der Wechsel von der seriellen Schleife auf einen Thread-Pool hat ihn von rund neun Minuten auf unter eine gedrückt, weil jeder Worker sein Leben blockiert auf einem Socket verbringt und das Lock währenddessen freigibt. Der Parsing-Schritt daneben hat null davon gehabt, also haben wir den stattdessen in einen Process-Pool geschoben. Numpy und andere C-Extensions geben das Lock in lang laufenden nativen Aufrufen ebenfalls ab, weshalb schwere Array-Mathematik selbst in Threads parallel aussehen kann. Wenn mir jemand sagt, Python könne keine Nebenläufigkeit, frage ich meistens zurück, welche Art er meint.