संभव है कि Rust बड़े पैमाने के concurrent user-space software के लिए उपयुक्त टूल न हो

 (bitbashing.io)
2 पॉइंट द्वारा GN⁺ 2023-09-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख बड़े पैमाने की concurrency वाले user-space software में Rust के उपयोग की चुनौतियों पर चर्चा करता है.
  • Rust का asynchronous model आधुनिक computing की दो मुख्य अवधारणाओं, concurrency और parallelism, को संभालने के लिए डिज़ाइन किया गया है.
    • Parallelism में कई CPU पर एक साथ code चलाना शामिल है.
    • Concurrency में समस्या को अलग-अलग करना, उसे स्वतंत्र हिस्सों में बाँटना, और उन्हें क्रम की परवाह किए बिना या आंशिक क्रम में चलाना शामिल है.
  • यह लेख महंगे inter-process communication के कारण concurrency के लिए कई process उपयोग करने की सीमाओं पर ज़ोर देता है.
  • वही memory साझा करने वाले process, यानी thread, को एक विकल्प के रूप में प्रस्तुत किया जाता है, लेकिन वे race condition और deadlock जैसी जटिल समस्याएँ पैदा कर सकते हैं.
  • Tony Hoare का 1978 का पेपर "Communicating Sequential Processes" यह प्रस्तावित करता है कि thread एक-दूसरे को message भेजने के लिए queue या channel का उपयोग करें, जिससे process जैसी isolation और आसान debugging जैसे कई फायदे मिलते हैं.
  • Rust की standard library में std::sync::mpsc::sync_channel के अंतर्गत channel शामिल हैं.
  • लेकिन web server जैसे, जो दसियों हज़ार उपयोगकर्ताओं से जुड़े होते हैं, उच्च स्तर की concurrency की आवश्यकता वाले मामलों में thread पर्याप्त नहीं हो सकते.
  • ऐसे परिदृश्यों के लिए Rust "async/await" model का उपयोग करता है, जिसमें function को asynchronous चिह्नित करने पर वह future या promise लौटाता है और परिणाम बनने तक प्रतीक्षा की जा सकती है.
  • इसके फायदों के बावजूद, asynchronous Rust में ऐसी चुनौतियाँ हैं जैसे compiler को यह विश्वास दिलाने की आवश्यकता कि सब कुछ ठीक रहेगा. यह raw thread की तुलना में कठिन हो सकता है.
  • "atomic reference count" या Arc का उपयोग एक समाधान के रूप में सुझाया जाता है, लेकिन यह garbage collector की समस्याओं जैसी दिक्कतें पैदा कर सकता है, इसलिए यह कोई सर्वव्यापी समाधान नहीं है.
  • लेख अंत में यह सुझाव देता है कि अन्य क्षेत्रों में Rust की ताकत के बावजूद, बड़े पैमाने की concurrency वाले user-space software के लिए यह सबसे उपयुक्त टूल नहीं हो सकता.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-09
Hacker News राय
  • लेखक Rust में एक हाई-परफॉर्मेंस metaverse client विकसित कर रहे हैं, जिसे रियल-टाइम में बड़ी मात्रा में डेटा प्रोसेस करना होता है।
  • लेखक का प्रोजेक्ट graphics rendering, network event processing, asset loading जैसी विभिन्न tasks के लिए कई threads का उपयोग करता है।
  • Rust इस प्रोजेक्ट के लिए फायदेमंद रहा है, और लेखक को आमतौर पर दूसरों के "unsafe" code की वजह से साल में लगभग एक बार memory-related crash का सामना करना पड़ा है।
  • लेखक Rust की आलोचना करते हैं कि इसमें race conditions तो नहीं होते, लेकिन deadlock नहीं होंगे ऐसा भी नहीं है, और वे static deadlock analyzer की आवश्यकता का सुझाव देते हैं।
  • लेखक Rust में async के व्यापक उपयोग की आलोचना करते हैं और दावा करते हैं कि यह compute-bound tasks के लिए उपयुक्त नहीं है और अलग-अलग priority पर चलने वाले threads के साथ compatible नहीं है।
  • लेखक का सुझाव है कि Rust की single ownership, जबकि back references के साथ एक आम आवश्यकता है, लेकिन इसे implement करना बहुत कठिन है।
  • लेखक मानते हैं कि Rust का game ecosystem गंभीर game development के लिए तैयार नहीं है, और उदाहरण के तौर पर Rust में non-toy graphics की कमी का उल्लेख करते हैं।
  • अन्य टिप्पणियाँ इस बात से सहमत हैं कि async Rust चुनौतीपूर्ण है और अक्सर अनावश्यक भी, और सुझाव देती हैं कि Go का सब कुछ sync बनाकर एक single async channel रखने वाला approach बेहतर हो सकता है।
  • कुछ commenters Rust ecosystem में async के व्यापक उपयोग की आलोचना करते हैं और दावा करते हैं कि यह program को पूरी तरह async बना देता है या कई चीजों के लिए tokio crate पर निर्भर होने को मजबूर करता है।
  • कुछ commenters का सुझाव है कि Rust की async functionality अभी भी विकासाधीन है, इसलिए इसकी वर्तमान स्थिति की आलोचना करना जल्दबाज़ी होगी।
  • एक commenter का तर्क है कि Rust का Arc कोई अज्ञात चीज़ नहीं है, बल्कि यह इस पर निर्भर करता है कि आप उसे कहाँ और कैसे रखते हैं, और उनका सुझाव है कि लेखक Rust पर अपना पुराना mental model थोपने की कोशिश कर रहे हैं।
  • कुछ commenters सामान्य रूप से async/await के उपयोग के विरोध में हैं और दावा करते हैं कि यह language और ecosystem को दो हिस्सों में बाँट देता है और लंबी अवधि की समस्याएँ पैदा करता है।
  • एक commenter का सुझाव है कि concurrency के लिए सही primitive Hoare की Communicating Sequential Processes है, जिसे Java (JDK17 के बाद - Java Virtual Threads), Go, और Kotlin में green threads पर मैप किए गए रूप में implement किया गया है।
  • एक commenter का सुझाव है कि async-scoped जैसे unsafe crate का उपयोग करके उन ज़्यादातर bugs को पकड़ लेना, जो C++ में लिखे जाने पर होते, एक उचित compromise है।