CPython GIL’ini isteğe bağlı hâle getiren PEP 703’ün kabul edilme niyeti
(discuss.python.org)- Python Steering Council, CPython’da GIL’i isteğe bağlı hâle getiren PEP 703’ü kabul etmeye hazırlanıyor; no-GIL önerisine ve PEP 703’e yönelik topluluk tepkisi de genel olarak olumlu
- Uzun vadeli hedef, no-GIL derlemesinde tekleşmek; with-GIL ve no-GIL derlemelerinin ve genişletme modülü ekosisteminin kalıcı olarak ayrıştığı bir durumdan kaçınılmak isteniyor
- Geçiş sürecinde geriye dönük uyumluluk temel kısıt; no-GIL desteği için değiştirilen üçüncü taraf kodlarının da with-GIL derlemesinde çalışmaya devam etmesi gerekiyor
- Plan, kısa vadeli deneysel derleme, orta vadeli desteklenen derleme ve uzun vadeli varsayılan derleme olmak üzere 3 aşamalı geçiş; deneysel derleme Python 3.13’e girebilir, ancak 3.14’e sarkması da sorun olarak görülmüyor
- Varsayılan derlemeye geçmeden önce topluluk desteği ile API, paketleme ve dağıtım deneyiminin doğrulanması gerekiyor; karmaşa faydadan büyük olursa PEP 703 durdurulmalı ve başka çözümler aranmalı
Steering Council’ın PEP 703’ü kabul etme yönündeki yaklaşımı
- Python Steering Council, PEP 703’ü kabul etme niyetinde
- no-GIL önerisi anketinde genel olarak olumlu tepkiler geldi; Steering Council da hem genel fikre hem de PEP 703’e büyük ölçüde olumlu bakıyor
- Ancak kabulün ayrıntıları hâlâ üzerinde çalışılıyor ve önümüzdeki birkaç hafta içinde nihai hâle getirilecek
Kalıcı çatallanma olmadan ilerleme ilkesi
- Uzun vadede, muhtemelen 5 yıldan uzun bir süre içinde no-GIL derlemesi tek derleme hâline gelmeli
- with-GIL derlemesi ile no-GIL derlemesinin kalıcı olarak ayrıldığı bir durum istenmiyor
- Genişletme modülü ekosisteminin de iki derlemeye kalıcı olarak bölündüğü bir yapıdan kaçınılmak isteniyor
- Geriye dönük uyumluluk çok dikkatli ele alınmalı
- Bir başka Python 3 geçişi durumu yaratılmak istenmiyor
- no-GIL derlemesini desteklemek için üçüncü taraf kodu değiştirilse bile, bu değişiklik with-GIL derlemesinde de çalışmalı
- Önceki Python sürümleriyle geriye dönük uyumluluk sorunları ayrıca ele alınmalı
- Bu Python 4 değil
- ABI uyumluluk gereksinimleri, iki derlemenin ayrıntıları ve geriye dönük uyumluluğa etkileri hâlâ inceleniyor
Varsayılanı değiştirmeden önce doğrulanacak koşullar
- no-GIL derlemesini varsayılan yapmadan önce topluluk desteğinin yeterli olduğundan emin olunmalı
- Yalnızca varsayılanı değiştirip topluluğun yapılması gereken işleri kendi başına bulmasını beklemek doğru olmaz
- Çekirdek geliştiriciler yeni derleme modunu ve çevresindeki unsurları bizzat deneyimlemeli
- Mevcut kodun thread safety durumunu düzene sokarken yeni C API ve Python API gerekebilir
- Bu süreçte elde edilen içgörüler Python topluluğuyla paylaşılmalı
- Çekirdek geliştiricilerin istediği değişikliklerin ve topluluktan istenecek değişikliklerin kabul edilebilir düzeyde olup olmadığı doğrulanmalı
- no-GIL varsayılan hâle gelmeden önce, değişikliklerin çok büyük bir karmaşa yarattığı ve faydanın küçük kaldığı düşünülürse yön değiştirilebilmeli
- Bu durumda tüm çalışmaları geri alma kararı da mümkün olmalı
- Bu nedenle no-GIL’e özel kod bir ölçüde tanımlanabilir olmalı
3 aşamalı geçiş planı
- Kısa vadede no-GIL derlemesi deneysel derleme modu olarak eklenir
- Muhtemelen Python 3.13’e girebilir
- Python 3.14’e sarkması da sorun olarak görülmüyor
- Deneysel durum, çekirdek geliştiricilerin bu derleme modunu desteklediğini ancak topluluğun hemen desteklemesinin beklenemeyeceğini netleştirmek içindir
- API tasarımı, paketleme ve dağıtım açısından topluluk desteğini mümkün kılmak için zamana ihtiyaç var
- Dağıtımların deneysel no-GIL derlemesini varsayılan yorumlayıcı olarak sunması önerilmiyor
- Orta vadede no-GIL derlemesi desteklenen hâle getirilir, ancak henüz varsayılan yapılmaz
- Üretim kullanımına elverecek kadar topluluk desteği olduğuna dair güven gerekiyor
- Bu aşamada no-GIL’i varsayılan hâle getirmek için hedef tarih veya Python sürümü belirlenir
- Zamanlama; API değişikliklerinin geriye dönük uyumluluğuna, stable ABI’ın ele alınışına ve topluluğun gerekli gördüğü iş miktarına büyük ölçüde bağlıdır
- En az 1-2 yıl, hatta daha uzun sürebilir
- Desteklenen olarak ilan edildiğinde bazı dağıtıcılar no-GIL’i varsayılan olarak sunmaya başlayabilir; ancak bu, o dönemde kaç Python paketinin no-GIL’i desteklediğine bağlı olabilir
- Uzun vadede no-GIL varsayılan yapılmak ve GIL’in izleri kaldırılmak isteniyor
- Gereksiz yere geriye dönük uyumluluk bozulmaz
- İki yaygın derleme modunu uzun süre korumak, test kaynakları ve hata ayıklama senaryolarının iki katına çıkması gibi nedenlerle topluluk üzerindeki yükü artırabilir
- Buna rağmen acele edilemez; bu aşamaya gelmek en fazla 5 yıl sürebilir
Sürekli yeniden değerlendirme ve durdurma olasılığı
- Tüm süreç boyunca yalnızca Steering Council değil, çekirdek geliştiriciler de ilerlemeyi ve önerilen takvimi sürekli yeniden değerlendirmeli
- Bu çalışmanın bir başka 10 yıllık geriye dönük uyumluluk mücadelesine dönüşmesi istenmiyor
- PEP 703’ün sorun yaratacağına dair işaretler görülürse durdurulup başka çözümler aranabilmeli
- Devam eden çalışmanın buna değip değmediği düzenli olarak kontrol edilmeli
1 yorum
Hacker News yorumları
On yıllar boyunca pek çok C kütüphanesi kodunun kılavuzlarında asenkron, yeniden girişli ve özyinelemeli bağlamlarda kararsız olduğuna dair uyarılar vardı.
Yine de bununla başa çıkmayı öğrendik; API kararsızlığını fazla büyütmeden yeniden girişe güvenli sürümler kademeli olarak dağıtıldı.
Yerinde token’lara ayıran string ayrıştırma, statik tampon kullanan DNS çağrıları, Vax’e özgü yığın davranışına bel bağlayan kodlar gibi şeyler vardı; bence GIL hem nimet hem de lanetti.
Bu sayede, bir API’yi az çok bilsem bile önemli bir ayrıntıyı kaçırmış ya da bir şey değişmiş olabilir mi diye belgelere bakma alışkanlığı edindim sanırım.
O dönem platformlar arası C++ yaparken ilk kez gördüğüm Java, eşzamanlılık, çöp toplama ve C++’tan daha kolay kullanılabilen birçok özelliği baştan sunuyordu; çok büyüyeceğinden emindim.
Sonrasında ana akım geliştiriciler Python kullanmaya başladı; hatırladığım kadarıyla aslında gömülebilir bir eklenti dili olduğu için basitti, bu yüzden GIL de daha anlamlıydı.
Birinin düğmeye basıp bir sürü şüpheli C kodunu tek seferde kırması söz konusu değil.
Artık 128 çekirdekli CPU’lar bile var; düşük maliyetli CPU’ların bile 6 çekirdeğe sahip olduğu bir çağda, tek çekirdek performansına bağlı kalma kısıtı zamanla daha da büyüyor.
Başta bunun birkaç hafta, en fazla birkaç ay içinde çözülecek bir sorun olduğuna inanıyordum; meğer ne kadar az biliyormuşum.
C’de iş parçacığı güvenli olmayan fonksiyonlarla etkileşim çok daha doğrudan ve C kullanırken genellikle daha dikkatli olunur.
Python’da ise küresel duruma sahip C modülleri bütün hâlinde var; bunlardan 10 kadarını yükleyip üzerine yorumlayıcının karmaşıklığını ekleyince, kısa sürede kimse ne olup bittiğini bilemez hâle gelir.
Bugün bile çoğu geliştirici, hatta çekirdek geliştiricilerin bile çoğu bellek sızıntılarını kontrol etmiyor; tsan çalıştıracaklarını sanmıyorum, çalıştırsalar bile muhtemelen kodun yalnızca %10’unu kapsayan küçük bir test seti olur.
Python’daki, özellikle de yapay zeka tarafındaki yazılım geliştirme pratiklerine bakınca bu özellik konusunda oldukça kötümserim.
İlginç aslında.
Python, çoğunlukla küresel kilide güvenilebileceği bilgisiyle yazılmış C paylaşımlı kütüphanelerinden oluşuyor.
Bazıları yeterince basit olduğu için kilitsiz de iyi çalışabilir, ama diğerlerinin hâlâ kilide ihtiyacı olacak ve artık GIL olmadan çalışmaları yönünde baskı görecekler.
Bunların bir kısmı kendi kapsamı içinde doğrudan kilit uygulayacak; belki de Python’da gerçekten eksik olan şey, ekosistemin dört bir yanına dağılmış geçici mutex çağrılarıydı.
Python’ın performans gerekçesiyle veri yarışları ve deadlock’lar sokularak bozulacağını beklemezdim.
Küresel kilit varsayımıyla yazılmış bir C kütüphanesini iş parçacığı güvenli hâle getirmek, eşzamanlılık uzmanlarının bile önermeyeceği ve uygularken hata yapılması muhtemel türden bir iş.
Benim varsayımım, Python C eklentisi yazanların çoğunun eşzamanlılık uzmanı değil, meydan okumadan kaçınmayan iyi programcılar olduğu; bu kombinasyonda veri yarışı/takılma/segfault neredeyse kaçınılmaz görünüyor.
Ancak 5 yıl sonra opt-in’e çevrileceği beklentisi fazla iyimser.
Tüm kütüphane geliştiricilerinin kendi kütüphanelerini, hatta Python kütüphanelerini düzeltmesi gerekecek; bu zor bir iş ve iyi yapılsa bile kimse fark etmeyeceği için karşılığını almak zor.
Çoklu işlem kullanım senaryosu hiç olmayan çok sayıda kütüphane de var; büyük kütüphanelerde ince hataların ortaya çıkması kaçınılmaz olduğundan, yeniden üretilemeyen şikâyetler ve geliştiricilerin pes etmesi garanti sonuç gibi görünüyor.
GIL’li Python da iş parçacıklarını desteklediği için bu kütüphaneler en azından yeniden girişe güvenli olmalı.
Yeniden girişli olup iş parçacığı güvenli olmayan bir kütüphane söz konusuysa, tüm çağrıları saran tek bir küresel kilit eklemek yeterli olabilir; bu da GIL’in yaptığı işe epey benzer.
Mevcut kütüphaneleri GIL olmadan çalışır hâle getirmek birçok durumda görece düz bir iş gibi görünüyor; paralellikten fedakârlık edilebilir.
Asıl sorun, C tarafından Python çalışma zamanına callback yapan kütüphaneler gibi görünüyor.
Safça bir soru ama asyncio ve multiprocessing paketleri varken No-GIL'e kimin ihtiyaç duyacağını merak ediyorum.
Python'da GIL yüzünden hiç sorun yaşamadım; ThreadPool ya da ProcessPool başlatarak veya gerekirse asenkron kütüphaneler kullanarak hep etrafından dolaştım.
multiprocessing ile çözülemeyen No-GIL kullanım senaryoları var mı merak ediyorum.
Eşzamanlılık ilkel araçlarının ek yükü olmadan tek iş parçacıklı çalışmanın yüksek performanslı hesaplama için en iyisi olduğunu düşünürdüm. LMAX Disruptor'ın gösterdiği gibi.
asyncio doğası gereği tek iş parçacıklı olduğu için tek çekirdeklidir; multiprocessing ise çok çekirdekli olduğu için performans açısından daha iyidir ama her süreç görece ağırdır ve paylaşımlı bellek ek yükü getirir.
GIL tabanlı çok iş parçacıklılık tek çekirdeklidir ve doğru kullanması da zordur.
No-GIL çok iş parçacıklılık çok çekirdeklidir ama kullanımı zordur; uygulamasını tam bilmiyorum ama paylaşımlı belleğin multiprocessing'den daha hızlı olması gerekir.
Yeni bir sistem tasarlıyor olsam, neredeyse tüm Python kullanım senaryolarında iş parçacıklarına dokunmayıp asyncio/multiprocessing kullanma konusunda hemfikirim.
Hızlı çok iş parçacıklılık gerektiren Python programlarının çoğu baştan Python ile yazılmamalıydı; ancak CPU yoğun kodu zaten Python ile yazmış insanlar olduğu için No-GIL pratik bir çözümdür.
Paylaşılan durum kullanarak birden fazla istemciye aynı anda yanıt veren bir web sunucunuz varsa, multiprocessing veri gönderip alırken pickle kullandığı için performans ek yükü büyüktür.
Örneğin bellekte 1 GB'lık bir veri yapısı tutup paralel hesaplama yapmak istiyorsanız, multiprocessing'in bunu iyi performansla işlemesi zordur.
pickle kullanınca tüm nesneleri paylaşamazsınız; pickle edilemeyen nesne hatalarını karmaşık veri yapılarında ayıklamak çok zordur.
Özellikle yerel kütüphanelerin oluşturduğu nesneler paylaşılamayabilir.
Çalışma sırasında durum paylaşması gereken işlemler de multiprocessing modülüyle çok zordur; Flask için Prometheus exporter bile tüm süreçlerin istatistiklerini toplamak için geçici dizin kullanan tuhaf bir hack'e ihtiyaç duyar.
DeepMind'ın birçok uygulamasında süreç başına yaklaşık 50-100 iş parçacığı çalıştırmak istediklerini, ancak çoğu zaman 10'un altında bile GIL'in darboğaz oluşturduğunu söylüyor.
Geçici çözüm olarak alt süreçler de kullanıyorlar, ancak birçok durumda süreçler arası iletişim ek yükü çok büyüyor ve sonunda Python kod tabanının büyük bölümlerini C++'a taşımak zorunda kalıyorlar.
Web uygulamaları gibi ortalama kullanımlarda multiprocessing yeterli olabilir; fakat Google ve DeepMind gibi büyük ölçekli AI iş yüklerinde GIL, Python kullanımını gerçekten sınırlıyor.
Meta'nın bu işe 3 mühendis-yılı ayırmak istemesinin nedeni de bu: https://news.ycombinator.com/item?id=36643670
Adından da anlaşılacağı gibi gerçekten yalnızca I/O-bound problemlerde yardımcı olur.
Birden çok süreç arasında veri paylaşmak muazzam bir acıdır; veri kontrolüyle süreç orkestrasyonunu birlikte yapmak daha da büyük bir acıdır.
Süreçler pahalıdır ve az önce bahsedilen veri paylaşımı zorlukları yüzünden greenlet de gerçek bir alternatif olmakta zorlanır.
Ancak Python'ın büyük yer tuttuğu AI ve veri bilimi gibi alanlarda, çok sayıda CPU/GPU-bound iş parçacığını ayağa kaldırıp çalıştırabilmek büyük bir avantajdır.
Birçok C uzantısı çok iş parçacıklılık düşünülerek yazılmadığı için sorun çıkabilir; hatta muhtemelen çıkacak.
lstbaşka bir iş parçacığından erişilebiliyorsa güvenli olmayan küçük bir örnek burada: https://news.ycombinator.com/item?id=36649769Şu anda bile C kodu
__del__metodu üzerinden Python bayt koduna geri çağrı yaparsa ve o bayt kodu yeterince uzunsa, muhtemelen 100 komut civarında bir bağlam değişimi gerçekleşebilir.Ancak bu son derece nadir bir durum ve birçok C uzantısı kodu bu tür durumlar düşünülerek yazılmıyor.
C uzantısı kullananlar bunların atomik çalıştığı varsayımına dayanıyor olabilir.
Örneğin bir thread pool'da numpy dizilerine veri koyup alma yöntemi şu anda iyi çalışıyor, ama GIL yoksa bozulabilir.
Bu yüzden öneri ve çalışma yönü, non-GIL modunu tamamen isteğe bağlı bırakıp varsayılan yapmamak.
Bunu açıp kullanacak cesur azınlığın, onlarca yıllık Python kütüphane kodunda ince race condition'ları bulup düzeltmek için muazzam zaman harcamaya hazır olması gerekecek.
Erken benimseyenler ya çok acı çekecek ya da daha büyük olasılıkla non-GIL'i bağımlılıkları olabildiğince azaltılmış, çok özelleşmiş özel süreçlerle sınırlı tutacak.
Sorun olabileceğinden şüphelenilen bir durumdan, sorunun tam olarak nerede olduğunu bilinen bir duruma geçiliyor; geriye de o listeyi tek tek azaltmak kalıyor.
Kodun etrafına bir tür mutex eklenebilir ya da daha az sorun çıkaracak, native kod olmayan alternatif bir uygulamaya geçilebilir.
Karşı argüman çoğunlukla işin çok olduğu yönünde; imkânsız olduğu yönünde değil gibi.
Yapacak yeterince insan varsa sonuç alınabilir.
Aksi olsaydı, insanların No-GIL modunu kendilerinin seçmesini sağlayan kademeli yaklaşım yerine GIL'i bir anda tamamen kaldırma planı açıklamış olurlardı.
Metinden Unicode’a geçişi, 32 bitten 64 bite geçişi, Intel’den ARM’a geçişi ve Y2K’yı hatırlamak yeterli
No-GIL çok daha küçük bir değişiklik ve radikal biçimde kırmadan aynı geçiş yolunu izleyebilir
Kırılan şeyler olsa bile, bu durumları ele almak için iyi tanımlanmış bir yol olacaktır
Sonuçta o geçişlerin hepsinden sağ çıktık ve ilerleme görmek sevindirici
Şimdiye kadar imkânsız olarak işaretlenmiş daha fazla alanı açacak
Erken dönem Swift’in iyi yaptığı şeylerden biri, kırıcı değişiklikleri vaatlerin içine koymasıydı; herkes nerede durduğunu biliyordu ve iyi uyum sağladı
Bazen Python’ın da aynı yolu seçmesini isterim
32 bitten 64 bite, ARM’a ve Y2K’ya geçişlerin hepsinde çalışıp çalışmadığı test edilebiliyordu
Elbette testler hata vakalarını kapsamamış olabilir, ama yapılan testler belirleyiciydi
Burada ise ne kadar test ederseniz edin yanıt “doğru ya da henüz doğru race condition’a dokunmadınız” oluyor
Python 3 geçiş senaryosunu tekrarlamak istemediklerini açıkça söyleseler de, mevcut yaklaşım ürkütücü derecede o yola yakın görünüyor
Bunun büyük kısmı Python topluluğuna ve dağıtım kanallarına bağlı
Topluluk zamanında benimseyemeyebilir ya da Ubuntu, Fedora, Anaconda gibi dağıtımlar aceleyle öne geçebilir
Kesin konuşmak için erken, ama bu tür bir senaryodan kaçınmak için Steering Council’ın gerçekte ne kadar kontrol gücü olduğu konusunda şüpheliyim
Python’ın iki modu olması için 5 yıl çok uzun
Yarım on yıl, iki modun statüko olarak yerleşmesi için yeterli ve sonrasında da eski Stack Overflow yazıları kalmaya devam edecek
5 yılın 10 yıllık belirsizliğe ve kırılmaya uzamayacağı konusunda iyimser değilim
Öte yandan 5 yıl, tüm C kodlarını ortaya çıkarıp düzeltmek, test etmek ve olgunlaştı demek için de fazla kısa olabilir
Destek sözü veren şirketler bazı projeleri mekanik olarak dönüştürecek, gerçek geliştiricileri rahatsız edebilecek ya da fork ile tehdit edebilecek
Hatalar, gerçek ücretsiz geliştiriciler tarafından yıllar içinde giderilip cilalanacak
Ama Python’ın bir tür “başarı”ya ihtiyacı var ve bu iyi bir tanıtım söylemi oluyor
Python dünyasında doğruluk pek önemli değil gibi görünüyor
Bu tarihçe yüzünden, başka bir büyük geçişe gitmektense CPython 3 içinde iki çalıştırma modunu korumaya çalışıyorlar gibi geliyor
Bunun kolayca bir Python 4 felaketine dönüşebileceğinin gayet farkında olmaları iyi
yes-GIL davranışını kazara etkilememek için son derece dikkatli olmak gerekiyor
Bir tür emüle edilmiş GIL gerçek GIL ile birebir aynı değilse her türlü tuhaf vaka mümkün
Birincisi, böyle olmasını istemiyorlar
İkincisi, böyle olursa hızla vazgeçecekler
İkisi de önemli, ama “ve bunu şu şekilde başaracağız” diyen kritik üçüncü parça eksik gibi görünüyor
GIL ve No-GIL’in 5 yıldan uzun süre birlikte var olabileceğini şimdiden söylüyorlar
Araç geliştiriciler için bu, en azından önümüzdeki 5 yıl boyunca maliyetin ikiye katlanması anlamına geliyor
Çünkü ister üretim amaçlı ister deneysel olsun, insanlar araçları iki modda da kullanmak isteyecek
GIL, Global Interpreter Lock demektir
İyi bir açıklama burada: https://realpython.com/python-gil/
Burada iki büyük sorun var
Birincisi, bazı iyileştirmeler geriye dönük uyumluluğu kırmaya değer ve GIL’in kaldırılması böyle bir iyileştirme
Python 3’teki değişikliklerin buna değip değmediği tartışmalı;
print’in fonksiyon olması özellikle değerli görünmüyorYine de 2-to-3 geçişi, sesi çok çıkan bir azınlık tarafından abartılmıştı; 5’ten fazla kod tabanını 2’den 3’e taşımış biri olarak çoğunda sorun azdı
En büyük sorun, önceki geliştiricilerin her şey için kütüphane çekmesi yüzünden bakımsız kütüphane yığınlarına dönüşmüş kod tabanlarıydı; bu tür kodlar, çekirdek dil uyumluluğu bozmasa bile sorun yaşar
Cevap, dili sonsuza dek uyumluluk bozamaz hale getirmeye zorlamak değil; tüm pip’i içeri çekmenin sürdürülebilir bir strateji olmasını beklememektir
Şu anda Steering Council, sesi çok çıkan azınlıktan o kadar çok eleştiri aldı ki kırıcı değişikliklerden korkar hale gelmiş durumda
Ama GIL’in kaldırılması, Python’ın çalışma biçiminin o kadar temel bir parçası ki kırıcı bir değişiklik olmalı; bunu kabul edip geçiş planı yapmak daha iyi, kullanıcıdan korkup gerçeği kabul edemeden bunu kırıcı olmayan hale getirmeye yönelik imkânsız bir işi denemek kötü bir fikir
Python 3.11’de de benim kod tabanım kırıldı ve düzeltmesi zor değildi, ama böyle bir şeyin olabileceğine dair iletişimin daha iyi olmasını isterdim
İkincisi, Python’ın diğer pek çok özelliğinin GIL etrafında tasarlanmış olması daha temel bir sorun
Özellikle asenkron paradigma GIL yüzünden çok anlamlı; GIL olmasaydı, geriye dönüp bakınca Erlang tarzı send/recv aktör modeli çok daha iyi bir yön olurdu
Bunu geri almak zor ve Python, birbirine pek uymayan özelliklerden oluşan daha az bütünlüklü bir kümeye itiliyormuş gibi hissettiriyor; bu yüzden çok geç ve çok az yapılmış gibi görünüyor
Python çekirdek geliştiricilerine ve Steering Council'a teşekkür ederim; Python, Java ve C ile birlikte sevdiğim dillerden biri
Python'da gerçek çoklu iş parçacığı desteğini büyük bir memnuniyetle karşılıyorum
Projeye bağlı olarak hem multiprocessing hem de multithreading kullanıyorum; multiprocessing örneği [0]'da, giriş/çıkış ağırlıklı işler için Python Threads kullandığım örnek ise [1]'de var
Ancak gerçek thread'ler kullanmak çok daha verimli olacaktır
Thread'ler, keyfi miktarda veriyi tek bir atomik ve neredeyse anlık işlemle alıp verebilir; yerel loopback arayüzü, multiprocessing veya pipe'larla bu mümkün değildir
“three tier multithreading architecture” adını verdiğim bir çoklu iş parçacığı mimarisi üzerinde çalışıyorum
https://github.com/samsquire/three-tier-multithreaded-archit...
Hedef, son derece ölçeklenebilir ve performanslı bir sunucu; ancak Python muhtemelen bu iş için doğru araç olmayabilir
[0]: https://news.ycombinator.com/item?id=36897054 multiprocessing kullanım açıklaması
[1]: https://devops-pipeline.com/ multithreading kullanım örneği