👧🏻 🐴 👏🏻 System.IO.Pipelines - उच्च प्रदर्शन के प्रेमियों के लिए एक अल्पज्ञात उपकरण 🤹🏻 🏅 🐩

नमस्कार पाठक। .NET Core 2.1 को रिलीज़ हुए काफी समय बीत चुका है। और स्पैन और मेमोरी जैसे शांत नवाचारों को पहले से ही काफी व्यापक रूप से माना जाता है, आप उनके बारे में बहुत कुछ पढ़, देख और सुन सकते हैं। हालाँकि, दुर्भाग्य से, System.IO.Pipelines नामक एक पुस्तकालय को समान ध्यान नहीं मिला। लगभग सब कुछ जो इस विषय पर है वह एकमात्र पोस्ट है जिसे कई लोगों ने घर पर अनुवादित और पोस्ट किया है। निश्चित रूप से अधिक जानकारी होनी चाहिए ताकि इच्छुक लोग विभिन्न कोणों से प्रौद्योगिकी को देख सकें।

परिचय

इसलिए, इस लाइब्रेरी का उद्देश्य स्ट्रीमिंग डेटा प्रोसेसिंग के साथ काम को गति देना है। यह मूल रूप से Kestrel (ASP.NET Core के लिए एक क्रॉस-प्लेटफ़ॉर्म वेब सर्वर) की विकास टीम द्वारा बनाया और उपयोग किया गया था, लेकिन वर्तमान में एक अलग नगेट पैकेज के माध्यम से वितरित किया जाता है।
इससे पहले कि हम विषय में तल्लीन हों, हम लाइब्रेरी तंत्र की मेमोरीस्ट्रीम के बेहतर एनालॉग के रूप में कल्पना कर सकते हैं। मूल मेमोरीस्ट्रीम की समस्या अत्यधिक संख्या में प्रतियां हैं, जो स्पष्ट है कि यदि आपको याद है कि एक निजी बाइट सरणी का उपयोग बफर के रूप में किया जाता है। उदाहरण के लिए, पढ़ें और लिखें विधियों में, प्रतिलिपि स्पष्ट रूप से दिखाई दे रही है। इस प्रकार, जिस ऑब्जेक्ट को हम स्ट्रीम पर लिखना चाहते हैं, उसके लिए आंतरिक बफर में एक कॉपी बनाई जाएगी, और पढ़ने के दौरान, आंतरिक कॉपी की एक कॉपी उपभोक्ता को वितरित की जाएगी। ऐसा लगता है कि अंतरिक्ष का सबसे तर्कसंगत उपयोग नहीं है।
System.IO.Pipelines सभी धाराओं को बदलने का लक्ष्य नहीं रखता है, यह एक डेवलपर के शस्त्रागार में एक अतिरिक्त उपकरण है जो उच्च-प्रदर्शन कोड लिख रहा है। मेरा सुझाव है कि आप खुद को बुनियादी तरीकों और कक्षाओं से परिचित कराएं, देखें कि वे अंदर कैसे व्यवस्थित होते हैं, और बुनियादी उदाहरणों का विश्लेषण करते हैं।

चलो आंतरिक डिवाइस से शुरू करते हैं, एक ही समय में सरल कोड टुकड़े की जांच करते हैं। उसके बाद, यह स्पष्ट हो जाएगा कि यह क्या और कैसे काम करता है, और इसका उपयोग कैसे किया जाना चाहिए। System.IO.Pipelines के साथ काम करते समय, यह याद रखने योग्य है कि मूल अवधारणा यह है कि सभी पढ़ने-लिखने का संचालन बिना किसी आवंटन के होना चाहिए। लेकिन कुछ तरीके जो पहली नज़र में आकर्षक हैं, इस नियम का खंडन करते हैं। तदनुसार, आप जिस कोड को बनाने के लिए बहुत कोशिश कर रहे हैं, वह नए और नए डेटा के लिए मेमोरी आवंटित करना शुरू कर देता है, कचरा कलेक्टर को लोड करना।

लाइब्रेरी की आंतरिक लाइब्रेरी भाषा के नवीनतम संस्करणों और समय-अवधि, स्पैन, मेमोरी, ऑब्जेक्ट पूल, ValueTask, आदि की व्यापक संभावनाओं का उपयोग करती है। यह उत्पादन में इन सुविधाओं का उपयोग करने के एक महान उदाहरण के लिए कम से कम देखने लायक है।
एक समय में, कुछ लोग C # में धाराओं के कार्यान्वयन से नाखुश थे, क्योंकि एक वर्ग का उपयोग पढ़ने और लिखने दोनों के लिए किया जाता था। लेकिन, जैसा कि वे कहते हैं, आप किसी वर्ग के तरीकों को फेंक नहीं सकते। यहां तक कि अगर स्ट्रीम ने पठन / लेखन / पॉइंटर को आगे बढ़ाने का समर्थन नहीं किया, तो CanRead, CanWrite और CanSeek संपत्तियों पर प्रभाव पड़ा, जो एक छोटी बैसाखी की तरह दिखती थी। यहां चीजें अलग हैं।
पाइप के साथ काम करने के लिए, 2 वर्गों का उपयोग किया जाता है: पाइपविटर और पाइपरीडर । इन कक्षाओं में लगभग 50 पंक्तियाँ होती हैं और ये छद्म-पहलू होते हैं (इसके सबसे क्लासिक अवतार नहीं, क्योंकि पाइप वर्ग के लिए एक ही वर्ग छिपा है, और कई नहीं), जिसमें डेटा के साथ काम करने के लिए सभी बुनियादी तर्क शामिल हैं। सार्वजनिक सदस्यों में से - 2 निर्माणकर्ताओं, 2 को केवल गुण मिलते हैं - रीडर और राइटर, रीसेट () विधि, जो आंतरिक क्षेत्रों को उनके प्रारंभिक राज्य में रीसेट करता है ताकि कक्षा का पुन: उपयोग किया जा सके। काम के लिए अन्य तरीकों को छद्म-पहलुओं का उपयोग करके कहा जाता है।

पाइप वर्ग पर आरंभ करने के लिए

क्लास का उदाहरण 320 बाइट्स पर है, जो कि बहुत अधिक है (लगभग एक किलोबाइट का एक तिहाई, ऐसी वस्तुओं में से 2 मैनचेस्टर मार्क I की याद में फिट नहीं हो सके)। इसलिए इसे बड़ी मात्रा में आवंटित करना एक बुरा विचार है। इसके अलावा, वस्तु का अर्थ दीर्घकालिक उपयोग के लिए अभिप्रेत है। पूल का उपयोग करना भी इस कथन के लिए एक तर्क देता है। आखिरकार, पूल में उपयोग की जाने वाली वस्तुएं हमेशा (किसी भी मामले में, मानक में) रहेंगी।
ध्यान दें कि वर्ग को सील के रूप में चिह्नित किया गया है और यह धागा सुरक्षित है - कोड के कई अनुभाग एक महत्वपूर्ण अनुभाग हैं और ताले में लिपटे हुए हैं।
आरंभ करने के लिए, आपको पाइप वर्ग का एक उदाहरण बनाने और उल्लिखित गुणों का उपयोग करके पाइपरीडर और पाइपविटर ऑब्जेक्ट प्राप्त करने की आवश्यकता है।

आसान आरंभीकरण

var pipe = new Pipe(); PipeWriter pipeWriter = pipe.Writer; PipeReader pipeReader = pipe.Reader;

पाइप के साथ काम करने के तरीकों पर विचार करें:
पाइपविटर के माध्यम से रिकॉर्डिंग के लिए - WriteAsync, GetMemory / GetSpan, Advance, FlushAsync, Complete, CancelPendingFlush, OnReaderCompleted।
पाइपराइडर के माध्यम से पढ़ने के लिए - एडवांसटॉ, रीडासिंक, ट्राइरेड, कम्प्लीट, कैंसलिंग, रीडिंग, ऑनड्राइटरकंप्लीट।

जैसा कि पोस्ट में कहा गया है , वर्ग बफ़र्स की एक एकल लिंक की गई सूची का उपयोग करता है। लेकिन, जाहिर है, वे पाइपरेडर और पाइपविटर के बीच पारित नहीं होते हैं - सभी तर्क एक वर्ग में हैं। इस सूची का उपयोग पढ़ने और लिखने दोनों के लिए किया जाता है। इसके अलावा, लौटा डेटा इस सूची में संग्रहीत है।
ऐसी ऑब्जेक्ट भी हैं जो पढ़ने के लिए डेटा की शुरुआत (रीडहेड और इंडेक्स), पढ़ने के लिए डेटा का अंत (रीडेल और इंडेक्स) और लिखने की जगह की शुरुआत (राइटहेड और लिखित बफ़र बाइट्स की संख्या) को इंगित करती हैं। यहां रीडहेड, रीडटेल और राइटहेड सूची से एक विशिष्ट खंड हैं, और सूचकांक खंड के भीतर एक विशिष्ट स्थिति को इंगित करता है। इस प्रकार, रिकॉर्डिंग एक खंड के बीच से शुरू हो सकती है, पूरे अगले खंड पर कब्जा कर सकती है और तीसरे के बीच में समाप्त हो सकती है। ये संकेत विभिन्न तरीकों से चलते हैं।

पाइपविटर विधियों से शुरू करना

# 1 ValueTask <FlushResult> WriteAsync (ReadOnlyMemory <बाइट> स्रोत, रद्दीकरण टिप्पणी रद्द करेंटोकन)

बस वह मोहक विधि। एक बहुत ही उपयुक्त और ट्रेंडी हस्ताक्षर है - ReadOnlyMemory, अतुल्यकालिक स्वीकार करता है। और कई को लुभाया जा सकता है, विशेष रूप से यह याद रखना कि स्पैन और मेमोरी इतनी तेज और शांत हैं। लेकिन अपने आप को चापलूसी मत करो। यह सब विधि जो करती है वह आंतरिक सूची में पढ़ी गई ReadOnlyMemory की प्रतिलिपि है। और "कॉपी" का अर्थ है कॉपीटो विधि के लिए एक कॉल, और ऑब्जेक्ट को स्वयं कॉपी नहीं करना। यही है, सभी डेटा जिसे हम रिकॉर्ड करना चाहते हैं, कॉपी किया जाएगा, जिससे मेमोरी लोड हो रही है। इस पद्धति का अध्ययन केवल यह सुनिश्चित करने के लिए किया जाना चाहिए कि इसका उपयोग न करना बेहतर है। खैर, और शायद कुछ दुर्लभ स्थितियों के लिए, यह व्यवहार उचित है।
विधि का शरीर एक महत्वपूर्ण खंड है, इस तक पहुंच एक मॉनिटर के माध्यम से सिंक्रनाइज़ की जाती है।

फिर सवाल उठ सकता है कि कैसे कुछ लिखें, अगर सबसे स्पष्ट और केवल उपयुक्त विधि के माध्यम से नहीं।

# 2 मेमोरी <बाइट> GetMemory (int sizeHint)

विधि पूर्णांक प्रकार के एक पैरामीटर को लेती है। इसमें हमें संकेत करना चाहिए कि हम कितने बाइट्स लिखना चाहते हैं (या अधिक, लेकिन किसी भी मामले में कम नहीं)। यह विधि जांचती है कि क्या _writingHeadMemory में संग्रहीत मेमोरी के वर्तमान टुकड़े में लिखने के लिए पर्याप्त जगह है। यदि पर्याप्त हो, तो _writingHeadMemory को मेमोरी के रूप में लौटाया जाता है। यदि नहीं, तो बफर को लिखे गए डेटा के लिए, लेकिन जिसके लिए फ्लशएस्क्यू विधि को नहीं बुलाया गया था, उसे कॉल किया जाता है और एक अन्य बफ़रसेलेक्ट चुना जाता है, जो पिछले एक से जुड़ा हुआ है (यहां सूची है)। _WritingHeadMemory की अनुपस्थिति में, इसे एक नए बफ़रशिप के साथ आरंभ किया जाता है। और अगले बफर का आवंटन एक महत्वपूर्ण अनुभाग है और लॉक के तहत किया जाता है।
मैं ऐसे उदाहरण पर एक नज़र डालने का सुझाव देता हूं। पहली नज़र में, ऐसा लग सकता है कि संकलक (या रनटाइम) ने दानव को आघात पहुँचाया है।

द्वेष

  var pipeNoOptions = new Pipe(); Memory<byte> memoryOne = pipeNoOptions.Writer.GetMemory(2); Console.WriteLine(memoryOne.Length); //2048  4096 var pipeWithOptions = new Pipe(new PipeOptions(minimumSegmentSize: 5)); Memory<byte> memoryTwo = pipeWithOptions.Writer.GetMemory(2); Console.WriteLine(memoryTwo.Length); //16

लेकिन इस उदाहरण में सब कुछ समझ में आता है और सरल है।
एक पाइप उदाहरण बनाते समय, हम इसे बनाने के लिए विकल्पों के साथ एक पाइप ऑक्शन ऑब्जेक्ट पास कर सकते हैं।

पाइप ऑयल्स में एक डिफ़ॉल्ट न्यूनतम खंड आकार क्षेत्र है। बहुत समय पहले यह 2048 नहीं था, लेकिन इस प्रतिबद्धता ने सब कुछ बदल दिया, अब 4096। लेखन के समय, 4096 वाला संस्करण एक प्रीलेयरेज पैकेज था, नवीनतम रिलीज संस्करण में यह 2048 था। यह पहले उदाहरण के व्यवहार को बताता है। यदि आप मानक बफर के लिए एक छोटे आकार का उपयोग करने के लिए महत्वपूर्ण हैं, तो आप इसे पाइपऑप्शन प्रकार के उदाहरण में निर्दिष्ट कर सकते हैं।

लेकिन दूसरे उदाहरण में, जहां न्यूनतम आकार का संकेत दिया गया है, लंबाई किसी भी तरह से मेल नहीं खाती है। और यह पहले से ही हो रहा है क्योंकि पूल का उपयोग करके एक नया बफ़रशिप का निर्माण होता है। पाइप ऑप्शन में से एक विकल्प मेमोरी पूल है। उसके बाद, एक नया खंड बनाने के लिए निर्दिष्ट पूल का उपयोग किया जाएगा। यदि आपने अपने मेमोरी पूल को निर्दिष्ट नहीं किया है, तो मानक ArrayPool का उपयोग किया जाएगा, जो कि आप जानते हैं, विभिन्न आकारों के सरणियों के लिए कई बाल्टी हैं (प्रत्येक अगले एक पिछले एक की तुलना में 2 गुना बड़ा है) और, जब एक विशिष्ट आकार के लिए कहा जाता है, तो यह उपयुक्त आकार के सरणियों के साथ एक बाल्टी की तलाश करता है (तब निकटतम सबसे बड़ा या बराबर है)। तदनुसार, नया बफ़र आपके द्वारा अनुरोधित की तुलना में लगभग निश्चित रूप से बड़ा होगा। मानक ArrayPool (System.Buffers.TlsOverPerCoreLockedStacksArrayPool) में न्यूनतम सरणी आकार 16 है। लेकिन चिंता न करें, क्योंकि यह सरणियों का एक पूल है। तदनुसार, अधिकांश मामलों में, सरणी कचरा संग्रहकर्ता पर दबाव नहीं डालती है और इसका पुन: उपयोग किया जाएगा।

# 2.5 स्पैन <बाइट> गेटस्पैन (int sizeHint)

यह इसी तरह से काम करता है, स्पैन को मेमोरी से देता है।

इस प्रकार GetMemory () या GetSpan () लेखन की मुख्य विधियाँ हैं। वे हमें एक वस्तु देते हैं जिसे हम लिख सकते हैं। ऐसा करने के लिए, हमें मूल्यों के नए सरणियों के लिए मेमोरी आवंटित करने की आवश्यकता नहीं है, हम सीधे आंतरिक संरचना में लिख सकते हैं। कौन सा उपयोग करना है यह मुख्य रूप से आपके द्वारा उपयोग किए जा रहे एपीआई और अतुल्यकालिक विधि पर निर्भर करेगा। हालांकि, उपरोक्त के मद्देनजर, एक सवाल उठता है। पाठक को कैसे पता चलेगा कि हमने कितना लिखा है? यदि हम हमेशा पूल के एक विशिष्ट कार्यान्वयन का उपयोग करते हैं, जो कि अनुरोध के समान आकार का एक सरणी देता है, तो पाठक एक बार में पूरे बफर को पढ़ सकता है। हालांकि, जैसा कि हमने पहले ही कहा है, हमें एक बड़े आकार की उच्च संभावना के साथ एक बफर आवंटित किया जाता है। यह ऑपरेशन के लिए आवश्यक निम्न विधि की ओर जाता है।

# 3 शून्य अग्रिम (इंट बाइट्स)

एक भयानक सरल विधि। यह एक तर्क के रूप में लिखे गए बाइट्स की संख्या लेता है। वे आंतरिक काउंटरों को बढ़ाते हैं - _unflushedBytes और _writingHeadBytesBuffered, जिनके नाम स्वयं बोलते हैं। यह भी लिखावट (स्लाइस विधि का उपयोग करके) बाइट्स की संख्या के लिए _writingHeadMemory को काटता है। इसलिए, इस पद्धति को कॉल करने के बाद, आपको मेमोरी या स्पैन के रूप में एक नए मेमोरी ब्लॉक का अनुरोध करने की आवश्यकता है, आप पिछले एक को नहीं लिख सकते। और विधि का पूरा शरीर एक महत्वपूर्ण खंड है और एक ताला के नीचे चलता है।

ऐसा लगता है कि इसके बाद पाठक डेटा प्राप्त कर सकता है। लेकिन एक और कदम की जरूरत है।

# 4 वैल्यूटैस्क <FlushResult> FlushAsync (कैंसिलेशनटोकन कैंसलेशनटोकन)

प्राप्त मेमोरी में आवश्यक डेटा लिखने के बाद विधि को कहा जाता है और यह दर्शाता है कि हमने वहां कितना लिखा है। विधि एक ValueTask देता है, हालांकि यह अतुल्यकालिक नहीं है (इसके वंशज StreamPipeWriter के विपरीत)। ValueTask एक विशेष प्रकार (रीडऑनली स्ट्रक्चर) है जिसका उपयोग उस स्थिति में किया जाता है जब अधिकांश कॉल अतुल्यकालिक का उपयोग नहीं करेंगे, अर्थात, इसके कॉल के समय सभी आवश्यक डेटा उपलब्ध होंगे और विधि सिंक्रोनाइज़ हो जाएगी। अंदर, इसमें या तो डेटा या टास्क होता है (यदि यह समकालिक रूप से काम नहीं करता है)। यह _writerAwaitable.IsCompleted property की स्थिति पर निर्भर करता है। यदि हम इस वेटिंग ऑब्जेक्ट की स्थिति को बदलते हैं, तो हम देखेंगे कि यह इस शर्त के तहत होता है कि अनप्रोसेस्ड (उपभोग नहीं किया गया) डेटा की मात्रा (यह बिल्कुल अपठित नहीं है (परीक्षित नहीं है), बाद में समझाया जाएगा कि एक निश्चित सीमा से अधिक है (_pauseWriterThreshold)। डिफ़ॉल्ट 16 खंड आकार है। यदि वांछित है, तो मान को पाइप ऑक्शन में बदला जा सकता है। इसके अलावा, यह विधि ReadAsync विधि की निरंतरता शुरू करती है, अगर कोई अवरुद्ध था।

एक FlushResult देता है जिसमें 2 गुण होते हैं - IsCanceled और IsCompleted। IsCanceled इंगित करता है कि क्या फ्लश रद्द कर दिया गया है (रद्द करें लंबित कॉल)। IsCompleted इंगित करता है कि क्या पाइप-राइडर पूरा हो गया था (पूर्ण) (या कम्पैरेसिंक्स () विधियों को कॉल करके)।
विधि का मुख्य भाग लोके स्काईवॉकर के तहत किया जाता है।

पाइपवर्टर के अन्य तरीके कार्यान्वयन के दृष्टिकोण से ब्याज के नहीं हैं और अक्सर बहुत कम उपयोग किए जाते हैं, इसलिए केवल एक संक्षिप्त विवरण दिया जाएगा।

# 5 शून्य पूर्ण (अपवाद अपवाद = अशक्त) या वैल्यूटैस्क कम्प्लीटैन्सिंक (अपवाद अपवाद = अशक्त)

लेखन के लिए मार्क्स पाइप बंद हो गए। पूरा होने पर, लिखने के तरीकों का उपयोग करने की कोशिश करते समय एक अपवाद फेंक दिया जाएगा। यदि पाइपराइडर पहले ही पूरा हो चुका है, तो पाइप का पूरा इंस्टेंस भी पूरा हो गया है। ज्यादातर काम ताला के नीचे किया जाता है।

# 6 शून्य रद्द करें लंबित ()

जैसा कि नाम से ही स्पष्ट है, यह वर्तमान फ्लुशएंशस () ऑपरेशन को पूरा करता है। एक लोक है।

# 7 शून्य OnReaderCompleted (क्रिया <अपवाद, ऑब्जेक्ट> कॉलबैक, ऑब्जेक्ट स्थिति)

पाठक के पूरा होने पर प्रतिनिधि को सौंप दिया जाता है। ताला भी है।
प्रलेखन वर्तमान में कहता है कि इस पद्धति को कुछ पाइपवर्टर वंशजों पर नहीं बुलाया जा सकता है और भविष्य में हटा दिया जाएगा। इसलिए, आपको इन तरीकों से तर्क नहीं बाँधना चाहिए।

पाइपरीडर पर जाएं

# 1 ValueTask <ReadResult> ReadAsync (रद्दीकरण टोकन टोकन)

यहाँ, फ्लुशसिंस्क की तरह, एक वैल्यूसैकट लौटाया गया है, जो संकेत देता है कि यह विधि अधिकतर तुल्यकालिक है, लेकिन हमेशा नहीं। _ReaderAwaitable की स्थिति पर निर्भर करता है। FlushAsync के साथ, आपको यह खोजने की आवश्यकता है कि _readerAwaitable अधूरा पर सेट है। यह तब होता है जब पाइपरीडर सूची से सब कुछ पढ़ता है (या इसमें वह डेटा शामिल है जिसे जांच के रूप में चिह्नित किया गया था और जारी रखने के लिए अधिक डेटा की आवश्यकता है)। जो, वास्तव में, तार्किक है। तदनुसार, हम यह निष्कर्ष निकाल सकते हैं कि अनुभवजन्य रूप से पहचाने गए आँकड़ों के आधार पर, अपने काम को ठीक से ट्यून करना वांछनीय है, इसके सभी विकल्पों को सोच-समझकर सेट करना। उचित कॉन्फ़िगरेशन एक अतुल्यकालिक निष्पादन शाखा की संभावना को कम करेगा और डेटा के अधिक कुशल प्रसंस्करण की अनुमति देगा। लगभग पूरी विधि एक ताला से घिरी हुई है।

रिटर्न कुछ रहस्यमय ReadResult । वास्तव में, यह ऑपरेशन की स्थिति को दर्शाने वाला सिर्फ एक बफर + झंडे है (रद्द किया गया - क्या ReadAsync को रद्द कर दिया गया था और यह इंगित करते हुए कि क्या पाइपवर्टर बंद था)। इस स्थिति में, IsCompleted एक मान है जो इंगित करता है कि क्या पाइपवर्टर कम्प्लीट () या कम्पैरेसिंक्स () विधियों को बुलाया गया था। यदि इन तरीकों को अपवाद के साथ बुलाया गया था, तो इसे पढ़ने की कोशिश करने पर फेंक दिया जाएगा।

बफ़र में फिर से एक रहस्यमय प्रकार है - ReadOnlySequence । यह, बदले में, संबंधित खंडों के अंदर आरंभ और अंत + प्रारंभ और समाप्ति सूचक खंड (ReadOnlySequenceSegment) के लिए एक वस्तु है। जो वास्तव में स्वयं पाइप क्लास की संरचना जैसा दिखता है। वैसे, BufferSegment ReadOnlySequenceSegment का उत्तराधिकारी है, जो बताता है कि इसका उपयोग वहां किया जाता है। इसके लिए धन्यवाद, आप लेखक से पाठक तक डेटा ट्रांसफर के लिए अनावश्यक मेमोरी आवंटन से छुटकारा पा सकते हैं।
आगे की प्रक्रिया के लिए ReadOnlySpan को बफर से प्राप्त किया जा सकता है। तस्वीर को पूरा करने के लिए, आप जांच सकते हैं कि क्या बफर में एकल ReadOnlySpan है। यदि इसमें शामिल है, तो हमें एक तत्व से संग्रह पर पुनरावृति करने की आवश्यकता नहीं है और हम इसे पहली संपत्ति का उपयोग करके प्राप्त कर सकते हैं। अन्यथा, आपको बफ़र के सभी खंडों पर जाने और प्रत्येक ReadOnlySpan को संसाधित करने की आवश्यकता है।

चर्चा का विषय - ReadOnlySequence वर्ग में अशक्त संदर्भ प्रकार सक्रिय रूप से उपयोग किए जाते हैं और गोटो (नेस्टिंग से बाहर निकलने के लिए नहीं और उत्पन्न कोड में नहीं) - विशेष रूप से, यहां

प्रसंस्करण के बाद, आपको पाइप उदाहरण से स्पष्ट करना होगा कि हम डेटा पढ़ते हैं।

# 2 बूल TryRead (बाहर पढ़ेंResult परिणाम)

तुल्यकालिक संस्करण। यदि यह है तो आपको परिणाम प्राप्त करने की अनुमति देता है। यदि यह पहले से ही नहीं है, तो ReadAsync के विपरीत यह ब्लॉक नहीं होता है, लेकिन गलत रिटर्न देता है। ताले में भी।

# 3 शून्य एडवांसटॉ (अनुक्रम अनुक्रम का सेवन, अनुक्रम जांच की गई)

इस पद्धति में, आप निर्दिष्ट कर सकते हैं कि हमने कितने बाइट्स पढ़े और कितने संसाधित किए। जो डेटा पढ़ा गया है लेकिन संसाधित नहीं है उसे अगली बार पढ़ने के बाद वापस कर दिया जाएगा। यह विशेषता पहली नज़र में अजीब लग सकती है, लेकिन बाइट्स की एक धारा को संसाधित करते समय प्रत्येक बाइट को व्यक्तिगत रूप से संसाधित करने के लिए शायद ही कभी आवश्यक होता है। आमतौर पर, संदेशों का उपयोग करके डेटा का आदान-प्रदान किया जाता है। ऐसी स्थिति उत्पन्न हो सकती है कि पढ़ने के दौरान पाठक को एक पूरा संदेश मिले और दूसरा भाग। पूरे को संसाधित किया जाना चाहिए, और दूसरे का हिस्सा अगली बार छोड़ दिया जाना चाहिए ताकि यह शेष भाग के साथ आए। AdvanceTo पद्धति एक SequencePosition को स्वीकार करती है, जो वास्तव में इसमें एक खंड + सूचकांक है। ReadAsync ने जो कुछ भी पढ़ा है, उसे संसाधित करते समय, आप बफर निर्दिष्ट कर सकते हैं। और। अन्यथा, आपको स्पष्ट रूप से एक स्थिति बनानी होगी, जो उस खंड और सूचकांक को इंगित करता है जिस पर प्रसंस्करण रोक दिया गया था। हुड के तहत।
साथ ही, यदि कच्ची जानकारी की मात्रा स्थापित दोष (_resumeWriterThreshold) से कम है, तो यह अवरुद्ध होने पर पाइपविटर की निरंतरता शुरू कर देता है। डिफ़ॉल्ट रूप से, यह दहलीज 8 खंड खंड (आधा अवरुद्ध दहलीज) है।

# 4 शून्य पूर्ण (अपवाद अपवाद = अशक्त)

पाइपरेडर को पूरा करता है। यदि इस बिंदु पर पाइपविटर पूरा हो गया है, तो संपूर्ण पाइप आवृत्ति समाप्त हो जाती है। अंदर से ताला।

# 5 शून्य रद्द करें लंबित ()

आपको वर्तमान में अपेक्षित पढ़ने को रद्द करने की अनुमति देता है। Loc।

# 6 शून्य OnWriterCompleted (क्रिया <अपवाद, ऑब्जेक्ट> कॉलबैक, ऑब्जेक्ट स्थिति)

आपको पाइपवर्टर के पूरा होने पर प्रतिनिधि को निर्दिष्ट करने की अनुमति देता है।
पाइपवर्टर के लिए समान विधि की तरह, प्रलेखन में एक ही नोट है जिसे हटा दिया जाएगा। हुड के नीचे ताला।

उदाहरण

नीचे दी गई सूची पाइपों के साथ काम करने का एक उदाहरण दिखाती है।
.NET कोर स्पैन और मेमोरी की शुरुआत के बाद से, डेटा के साथ काम करने के लिए कई वर्गों को इन प्रकारों का उपयोग करके ओवरलोड द्वारा पूरक किया गया है। तो सामान्य इंटरैक्शन स्कीम लगभग एक ही होगी। मेरे उदाहरण में, मैंने पाइप के साथ काम करने के लिए पाइपलाइन का उपयोग किया (मुझे मूल शब्द पसंद हैं), अर्थात। चैनल - इंटरप्रोसेस संचार के लिए ओएस ऑब्जेक्ट। चैनल एपीआई का विस्तार केवल स्पैन और मेमोरी में डेटा पढ़ने के लिए किया गया है। अतुल्यकालिक संस्करण मेमोरी का उपयोग करता है, क्योंकि अतुल्यकालिक विधि एक ऑटो-जेनरेट परिमित राज्य मशीन का उपयोग करके टेम्पलेट विधि में परिवर्तित हो जाएगी, जिसमें सभी स्थानीय चर और विधि पैरामीटर संग्रहीत किए जाते हैं, और चूंकि स्पैन रेफॉनली संरचना है, यह क्रमशः, स्पैन का उपयोग करके, ढेर पर नहीं हो सकता है। एक अतुल्यकालिक विधि में संभव नहीं है। लेकिन विधि का एक तुल्यकालिक संस्करण भी है जो आपको स्पैन का उपयोग करने की अनुमति देता है। मेरे उदाहरण में, मैंने दोनों की कोशिश की और यह पता चला कि इस स्थिति में सिंक्रोनस संस्करण खुद को बेहतर दिखाता है। इसका उपयोग करते समय, कम कचरा संग्रह होता है, और डेटा प्रोसेसिंग तेज होती है। लेकिन यह केवल इसलिए था क्योंकि बहुत अधिक डेटा था। इस घटना में कि एक स्थिति होने की संभावना है जिसमें अगले बैच के लिए आवेदन करने के समय कोई डेटा नहीं होगा, आपको एसिंक्रोनस संस्करण का उपयोग करना चाहिए ताकि प्रोसेसर बेकार न हो।
उदाहरण में ऐसी टिप्पणियाँ हैं जो कुछ बिंदुओं की व्याख्या करती हैं। मैं इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि इस तथ्य के बावजूद कि पाइप से पढ़ने और प्रसंस्करण के लिए जिम्मेदार प्रोग्राम के टुकड़े अलग हो जाते हैं, जब एक फ़ाइल पर लिखते हैं, तो डेटा उस जगह से बिल्कुल पढ़ा जाता है जहां वे पाइप से पढ़ते समय लिखे जाते हैं।

एक शक्तिशाली विशेषता के लिए विकास के वर्ष - अतुल्यकालिक मेन

  class Program { static async Task Main(string args) { var pipe = new Pipe(); var dataWriter = new PipeDataWriter(pipe.Writer, "testpipe"); var dataProcessor = new DataProcessor(new ConsoleBytesProcessor(), pipe.Reader); var cts = new CancellationTokenSource(); await Task.WhenAll(dataWriter.ReadFromPipeAsync(cts.Token), dataProcessor.StartProcessingDataAsync(cts.Token)); } }

PipeDataWriter

  public class PipeDataWriter { private readonly NamedPipeClientStream _namedPipe; private readonly PipeWriter _pipeWriter; private const string Servername = "."; public PipeDataWriter(PipeWriter pipeWriter, string pipeName) { _pipeWriter = pipeWriter ?? throw new ArgumentNullException(nameof(pipeWriter)); _namedPipe = new NamedPipeClientStream(Servername, pipeName, PipeDirection.In); } public async Task ReadFromPipeAsync(CancellationToken token) { await _namedPipe.ConnectAsync(token); while (true) { token.ThrowIfCancellationRequested(); ////       Memory<T> //Memory<byte> buffer = _pipeWriter.GetMemory(); ////       Memory<T> ////         -       . //int readBytes = await _namedPipe.ReadAsync(buffer, token); //         PipeWriter Span //         -       . int readBytes = _namedPipe.Read(_pipeWriter.GetSpan()); //      ,        //         if (readBytes == 0) { await Task.Delay(500, token); continue; } // ,       _pipeWriter.Advance(readBytes); //  ,      PipeReader FlushResult result = await _pipeWriter.FlushAsync(token); //  PipeReader  ,       //        ,      if (result.IsCompleted) { break; } } //  _pipeWriter     Pipe _pipeWriter.Complete(); } }

DataProcessor

  public class DataProcessor { private readonly IBytesProcessor _bytesProcessor; private readonly PipeReader _pipeReader; public DataProcessor(IBytesProcessor bytesProcessor, PipeReader pipeReader) { _bytesProcessor = bytesProcessor ?? throw new ArgumentNullException(nameof(bytesProcessor)); _pipeReader = pipeReader ?? throw new ArgumentNullException(nameof(pipeReader)); } public async Task StartProcessingDataAsync(CancellationToken token) { while (true) { token.ThrowIfCancellationRequested(); //     Pipe ReadResult result = await _pipeReader.ReadAsync(token); ReadOnlySequence<byte> buffer = result.Buffer; //      await _bytesProcessor.ProcessBytesAsync(buffer, token); // ,      .       ,   //  ,               //    IBytesProcessor.ProcessBytesAsync   ,    _pipeReader.AdvanceTo(buffer.End); //  PipeWriter  ,      //      ,      if (result.IsCompleted) { break; } } //  _pipeReader     Pipe _pipeReader.Complete(); } }

BytesProcessor

  public interface IBytesProcessor { Task ProcessBytesAsync(ReadOnlySequence<byte> bytesSequence, CancellationToken token); } public class ConsoleBytesProcessor : IBytesProcessor { //,         IDisposable readonly FileStream _fileStream = new FileStream("buffer", FileMode.Create); public Task ProcessBytesAsync(ReadOnlySequence<byte> bytesSequence, CancellationToken token) { if (bytesSequence.IsSingleSegment) { ProcessSingle(bytesSequence.First.Span); } else { foreach (var segment in bytesSequence) { ProcessSingle(segment.Span); } } return Task.CompletedTask; } private void ProcessSingle(ReadOnlySpan<byte> span) { _fileStream.Write(span); } }

System.IO.Pipelines - उच्च प्रदर्शन के प्रेमियों के लिए एक अल्पज्ञात उपकरण