PEP 703 वाली free-threaded build आपके लिखे कोड के लिए क्या बदल देती है?

free-threaded build, जो CPython 3.13 से एक ऑप्शनल इंटरप्रेटर के रूप में आती है, GIL हटा देती है ताकि कई थ्रेड्स एक साथ Python bytecode चला सकें। आपका कोड सच में कनकरेंट हो जाता है, यानी जिन races को GIL छिपा लेता था वे अब असली हैं। शेयर्ड म्यूटेबल स्टेट के चारों तरफ साफ तौर पर locks लगाने होंगे, और यह भी देखना होगा कि आपकी हर C extension इसे सपोर्ट करती है या नहीं।

Free threading 3.13 में एक experimental build के रूप में आई और तब से परिपक्व होती जा रही है, और अहम बात यह है कि यह एक अलग इंटरप्रेटर है जिसे आप खुद चुनते हैं, ऐसा कुछ नहीं जो चुपचाप सबके नीचे बदल गया हो। लॉक हटने के बाद दो थ्रेड्स एक साथ दो कोर पर bytecode चला सकते हैं, तो एक CPU bound वर्कर पूल आखिरकार process startup और pickling की कीमत चुकाए बिना स्केल करता है। सौदा शुद्धता का है। पुरानी build में बहुत सा लापरवाह कोड बिना synchronization के dict अपडेट करके बच निकलता था, क्योंकि bytecode boundary शायद ही कभी गलत जगह पड़ती थी। अब वे सच्ची data races हैं और आपको Lock या queue चाहिए। मैंने इसे एक scoring job पर आजमाया जो काम चार processes में बांट रही थी, और थ्रेड्स ने लगभग उतना ही throughput दिया, मेमोरी बहुत कम खाकर, क्योंकि मॉडल चार बार की जगह एक ही बार लोड रहा। प्रोडक्शन के लिए अड़चन extensions थीं। जिस भी चीज में C लेयर है उसे free threaded ABI के लिए दोबारा बिल्ड करना पड़ता है, तो इसे शिप करने से पहले मैं dependency tree का ऑडिट करूंगा और देखूंगा कि maintainers ने क्या पब्लिश किया है।