Rust के Pin के बारे में समझना

Pin

• Pin type और pinning की अवधारणा Rust के asynchronous ecosystem के बुनियादी building blocks हैं
• लेकिन Pin समझने में कठिन है और Rust के सबसे आसानी से गलत समझे जाने वाले हिस्सों में से एक है
• यह लेख बताता है कि Pin क्या हासिल करता है, यह कैसे आया, और आज Pin की समस्याएँ क्या हैं

Requirements

• asynchronous functions में references को support करने के लिए Future के अंदर references को store करना पड़ता था
• समस्या यह है कि ये references self-referential हो सकते हैं
• उदाहरण कोड:

  async fn foo<'a>(z: &'a mut i32) { ... }
  async fn bar(x: i32, y: i32) -> i32 {
      let mut z = x + y;
      foo(&mut z).await;
      z
  }
  

• Bar की internal state इस प्रकार है:

  enum Bar {
      Start { x: i32, y: i32 },
      FirstAwait { z: i32, foo: Foo<'?> },
      Complete,
  }
  

• Pin का लक्ष्य self-referential types को safely manipulate करना है

Non-solutions: move constructors and offset pointers

• move constructors और offset pointers Rust में काम नहीं करते
• move constructors move के समय pointers को modify करते हैं, लेकिन Rust में यह संभव नहीं है
• offset pointers भी काम नहीं करते, क्योंकि compile time पर यह पता नहीं हो सकता कि कोई reference self-referential है या नहीं

The “pinned typestate”

• कोई object हमेशा immovable नहीं होता, बल्कि किसी खास समय के बाद immovable होना चाहिए
• Ralf Jung के model में object "owned" state से "shared" state में, और फिर "pinned" state में जाता है
• pinned state में जाने के बाद object को अब move नहीं किया जा सकता

?Move

• Pin से पहले Move नाम के एक नए trait पर आधारित solution की कोशिश की गई थी
• जो types Move implement नहीं करते, वे reference लेने पर pinned state में transition हो जाते हैं
• लेकिन Move backward compatibility नहीं देता

Pin

• Pin object को pinned state में रखने के लिए एक नए reference type को design करता है
• Pin को library API के रूप में implement किया गया, जिससे backward compatibility बनी रहती है
• Unpin auto trait जोड़ा गया ताकि अधिकांश types pinned state और सामान्य state के बीच अंतर महसूस न करें

The problems with Pin

• usability के लिहाज़ से Pin में कई समस्याएँ हैं
• Pin को library type के रूप में implement किया गया है, इसलिए सामान्य reference types की कई सुविधाएँ गायब हो जाती हैं
• उदाहरण के लिए, &mut T Copy implement नहीं करता, फिर भी इसे कई बार argument के रूप में pass किया जा सकता है
• Pin यह सुविधा नहीं देता
• Pin का इस्तेमाल करते समय काफी भ्रम पैदा होता है

In my next post…

• Pin asynchronous functions में arbitrary references को safely compile होने देता है
• लेकिन Pin complexity बढ़ाता है, और अगली पोस्ट में इसे बेहतर करने के तरीकों पर चर्चा की जाएगी

GN⁺ का सार

• Pin Rust के asynchronous ecosystem का एक महत्वपूर्ण building block है
• Pin की usability समस्याएँ इसलिए हैं क्योंकि इसे library type के रूप में implement किया गया है
• Pin को बेहतर बनाने के तरीकों पर अगली पोस्ट में चर्चा की जाएगी
• इसी तरह की functionality वाले projects में pin-project-lite शामिल है

[GN⁺]

Hacker News राय

• Pin को समझना मुश्किल है क्योंकि आधिकारिक दस्तावेज़ इसे स्पष्ट रूप से नहीं समझाते

  • दस्तावेज़ कहते हैं कि "Pin यह गारंटी देता है कि object कभी move नहीं होगा", लेकिन यह वास्तव में सही नहीं है
  • अधिकांश सामान्य object Unpin होते हैं, इसलिए Pin आमतौर पर कोई काम नहीं करता
  • types T का वह समूह जिन पर Pin वास्तव में काम करता है, बहुत असामान्य है और दस्तावेज़ों में इस पर पर्याप्त ज़ोर नहीं दिया गया है

• Pin मुश्किल है क्योंकि अपने-आप में इसका कोई अर्थ नहीं है

  • Pin के मामले में, language या standard library यह नहीं बताती कि Pin क्या कर सकता है और क्या नहीं
  • इसके बजाय, InnerType देने वाला provider अतिरिक्त (अंदरूनी तौर पर unsafe) methods और API बनाता है ताकि pinned object को manipulate किया जा सके
  • Pin का अपने-आप में एकमात्र उद्देश्य ऐसा pointer देना है जो कम "built-in functionality" प्रदान करता है

• शीर्षक में "rust" जोड़ना चाहिए ताकि पता चले कि लेख किस बारे में है

• "value identity" शब्द Mojo के दस्तावेज़ों में कहीं भी परिभाषित नहीं है

  • Dave Abrahams का व्याख्यान "Value Semantics: Safety, Independence, Projection, & Future of Programming" सुझाया गया है

• Pin तकनीकी रूप से सही लेकिन समझने में कठिन नाम का एक अच्छा उदाहरण है

  • "Drop" का अर्थ ज़्यादा परिचित है, लेकिन "pinning" का नहीं
  • शायद immovable!(…) बेहतर हो सकता है, लेकिन इससे भी अच्छा नाम सोचना मुश्किल है
  • prevent_moving!(…) जैसा वर्णनात्मक नाम और PreventMove trait शायद बेहतर हो सकता है

• Rust जैसी language में अगर move-constructors हों, तो Pin की ज़रूरत खत्म हो सकती है

  • क्योंकि user के पास object को destroy करने का कोई तरीका नहीं होगा, इसलिए उसे move करने का भी कोई तरीका नहीं होगा

• &mut reference के ज़रिए mem::swap/replace से object को move किया जा सकता है, लेकिन वास्तव में इसकी ज़रूरत कम ही पड़ती है

  • काश move-reference चुनने का कोई तरीका होता
  • swap और replace को unsafe बनाना इस समस्या का समाधान हो सकता है

• WithoutBoats async iterators, poll, pin जैसे विषयों पर सक्रिय चर्चा कर रहे हैं

  • बहुत कम communities हैं जो language की बारीकियों पर सार्वजनिक रूप से इतनी गहराई से चर्चा करती हैं, और इसे देखना बहुत दिलचस्प है

• Pinning/!Move async/await के अलावा भी कई उपयोगों में काम आ सकता है

  • लेकिन Rust इसे ठीक से संभाल नहीं पाता, इसलिए आम जवाब होता है: "प्रोग्राम को किसी दूसरी language में फिर से लिखो"