👩🏾‍🏫 🖖🏿 🦍 स्टास अफानसैव। जूनो। Io.Reader / io.Writer पर आधारित पाइपलाइन। भाग 2 🔋 🤶🏿 👨🏾‍💼

रिपोर्ट में, हम io.Reader / io.Writer की अवधारणा के बारे में बात करेंगे कि इनकी आवश्यकता क्यों है, इन्हें सही तरीके से कैसे लागू किया जाए और इस संबंध में क्या नुकसान मौजूद हैं, साथ ही मानक और कस्टम io.eader / io.Writer कार्यान्वयन के आधार पर पाइपलाइनों के निर्माण के बारे में भी। ।

स्टास अफानसैव। जूनो। Io.Reader / io.Writer पर आधारित पाइपलाइन। भाग 1

बग "विश्वास पर"

एक अन्य बारीकियों: इस कार्यान्वयन में एक "बैगुल" है। इस बग की पुष्टि डेवलपर्स द्वारा की जाती है (मैंने इसके बारे में उन्हें लिखा था)। शायद किसी को पता है कि यह "बगुल" क्या है? यह स्लाइड पर स्थित है,

यह लयबद्ध रेखा है: यह लिपटे रीडर में बहुत अधिक विश्वास के साथ जुड़ा हुआ है: यदि रीडर नकारात्मक संख्या में बाइट्स लौटाता है, तो हम बाइट्स की संख्या को घटाकर प्राप्त होने वाली सीमा को बढ़ाना चाहेंगे। और कुछ मामलों में, यह एक बहुत ही गंभीर बग है जिसे आप तुरंत समझ नहीं सकते हैं।

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

मैं मानता हूं कि यह इष्टतम नहीं है। तो चलिए कुछ सुसंगत संस्करण पर आते हैं! हमारे पास मानक पुस्तकालय का एक कार्यान्वयन क्यों है जो किसी भी चीज़ पर भरोसा नहीं करता है, जबकि अन्य बिल्कुल सब कुछ पर भरोसा करते हैं?

सामान्य तौर पर, जब मैं अपनी नागरिक राय लिख रहा था, तो यह सोचकर, हमने इस मुद्दे को टिप्पणियों के साथ बंद कर दिया - “हम कुछ नहीं करेंगे। अलविदा"! उन्होंने मुझे किसी तरह का मूर्ख बना दिया ... विनम्रता, निश्चित रूप से, आप गलती नहीं पा सकते।

सामान्य तौर पर, अब हमें एक समस्या है। इसमें यह तथ्य शामिल है कि यह स्पष्ट नहीं है कि लिपटे रीडर के डेटा को कौन मान्य करना चाहिए। या तो ग्राहक, या हम पूरी तरह से अनुबंध पर भरोसा करते हैं ... हमारे पास एक समाधान है! अगर समय बचा है, तो मैं इसके बारे में बताऊंगा।

चलिए अगले मामले पर चलते हैं।

Teereader

हमने एक उदाहरण देखा कि कैसे रीडर डेटा लपेटें। पाइप का अगला उदाहरण राइटर में रीडर डेटा से आगे निकल जाना है। दो स्थितियां हैं।

पहली स्थिति। हमें रीडर से डेटा पढ़ने की जरूरत है, किसी तरह इसे राइटर (पारदर्शी रूप से) में कॉपी करें और रीडर के साथ काम करें। इसके लिए टी राइडर का कार्यान्वयन है। इसे ऊपरी कार्यान्वयन स्निपेट में प्रस्तुत किया गया है:

यूनिक्स पर टी टीम की तरह काम करता है। मुझे लगता है कि आप में से कई लोगों ने इस बारे में सुना है।
ध्यान दें कि यह कार्यान्वयन बाइट्स की संख्या की जांच करता है जिसे वह लिपटे रीडर से पढ़ता है। दूसरी पंक्ति में स्थितियां देखें? क्योंकि जब आप ऐसा कार्यान्वयन लिखते हैं, तो यह सहज रूप से स्पष्ट होता है: नकारात्मक संख्या के मामले में, आपको घबराहट होगी। और यह एक और जगह है जहां हम लिपटे रीडर पर भरोसा करते हैं! मैं आपको याद दिलाता हूं कि ये सभी मानक पुस्तकालय हैं।

चलो एक मामले पर चलते हैं, उदाहरण के लिए, इसका उपयोग कैसे करें। हम निचले स्निपेट पर क्या करेंगे? हम मानक http क्लाइंट का उपयोग करके golang.org से robot.txt फ़ाइल डाउनलोड करेंगे।

जैसा कि आप जानते हैं, http क्लाइंट हमारे लिए एक प्रतिक्रिया संरचना देता है, जिसमें बॉडी फ़ील्ड रीडर इंटरफ़ेस का कार्यान्वयन है। यह कहकर स्पष्ट किया जाना चाहिए कि यह ReadCloser इंटरफ़ेस का कार्यान्वयन है। लेकिन ReadCloser रीडर और क्लोजर से बनाया गया एक इंटरफ़ेस है। यही है, यह एक रीडर है, जो सामान्य रूप से बंद हो सकता है।

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

हमने अपने टीज़र को इकट्ठा किया और ReadAll का उपयोग करके इसे पढ़ा। सब कुछ अपेक्षित रूप से काम करता है: हम परिणामी निकाय को घटाते हैं, इसे एक फ़ाइल में लिखते हैं, और इसे असद में देखते हैं।

शुरुआती तरीका

दूसरी स्थिति। हमें सिर्फ रीडर के डेटा को पढ़ना है और उसे राइटर को लिखना है। समाधान स्पष्ट है ...

जब मैंने सिर्फ गो के साथ काम करना शुरू किया, तो मैंने एक स्लाइड पर इस तरह की समस्याओं को हल किया:

मैंने बफर स्थित किया, इसे रीडर से डेटा से भर दिया, और भरे हुए स्लाइस को राइटर में स्थानांतरित कर दिया। सब कुछ सरल है।

दो बिंदु। सबसे पहले, इस बात की कोई गारंटी नहीं है कि रीड विधि के लिए एक कॉल में पूरे रीडर को घटाया जाएगा, क्योंकि वहाँ डेटा छोड़ा जा सकता है (एक अच्छे तरीके से, यह एक लूप में किया जाना चाहिए)।

दूसरा बिंदु यह है कि यह पथ इष्टतम नहीं है। यहाँ सुंदर बॉयलरप्लेट कोड है जो हमारे सामने लिखा गया है।

इसके लिए, मानक पुस्तकालय में सहायकों का एक विशेष परिवार है - ये कॉपी, कॉपीएन और कॉपीबफ़र हैं।

io.Copy। राइटरटॉ और रीडरफ्रॉम

io.Copy मूल रूप से पिछली स्लाइड पर क्या करता है: यह 32 KB का एक डिफ़ॉल्ट बफर आवंटित करता है और रीडर से राइटर (इस कॉपी के हस्ताक्षर ऊपरी स्निपेट पर दिखाया गया है) पर डेटा लिखता है:

इस टेम्पलेट रूटीन के अलावा, इसमें यह शामिल है मुश्किल अनुकूलन की एक श्रृंखला। और इससे पहले कि हम इन अनुकूलन के बारे में बात करें, हमें दो और इंटरफेसों से परिचित होने की आवश्यकता है:

WriterTo;
ReadFrom।

काल्पनिक स्थिति। आपका रीडर मेमोरी बफर के साथ काम करता है। उन्होंने पहले ही इसे स्थानांतरित कर दिया है, लिखते हैं, वहां से कुछ पढ़ते हैं, अर्थात्, इसके तहत एक जगह पहले से ही स्थानांतरित हो गई है। आप इस पाठक को कहीं बाहर से पढ़ना चाहते हैं।

हमने पहले ही देखा है कि यह कैसे होता है: एक बफर बनाया जाता है, बफर पारित किया जाता है, जिसे रीड विधि को पारित किया जाता है; रीडर, जो मेमोरी के साथ काम करता है, इसे प्रतिकृति टुकड़े से बाहर फेंकता है ... लेकिन यह अब इष्टतम नहीं है - जगह को पुन: प्रस्तुत किया गया है। फिर से क्यों?

कहीं-कहीं 5-6 साल पहले (परिवर्तन सूची की एक कड़ी है) दो इंटरफेस बनाए गए थे: WriteTo और ReadFrom, जो स्थानीय रूप से लागू किए जाते हैं। रीडर ReadTo को लागू करता है, और राइटर ReadFrom को लागू करता है। यह पता चला है कि रीडर, पहले से ही दोहराया डेटा के साथ एक टुकड़ा होने, एक अतिरिक्त स्थान से बच सकते हैं और राइट टू राइटर्स विधियों को स्वीकार कर सकते हैं और अंदर उपलब्ध एक बफर पास कर सकते हैं।

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

रीडरफ्रॉम एक समान तरीके से काम करता है (यह केवल लेखक द्वारा लागू किया जाता है)। रीडरफ्रॉम पूरे रीडर को पढ़ता है, जो इसके लिए तर्क के रूप में आता है (ईओएफ से पहले) और लेखक के आंतरिक कार्यान्वयन में कहीं लिखता है।

CopyBuffer कार्यान्वयन

यह स्निपेट copyBuffer सहायक के कार्यान्वयन को दर्शाता है। इस गैर-निर्यात योग्य कॉपीबफ़र का उपयोग io.Copy, CopyN और CopyBuffer के हुड के तहत किया जाता है।

और यहां एक छोटी सी बारीकियों का उल्लेख करना लायक है। CopyN को हाल ही में ऑप्टिमाइज़ किया गया है - इस तर्क से अछूता। यह वही अनुकूलन है जिसके बारे में मैंने पहले कहा था: 32 KB का एक अतिरिक्त बफर बनाने से पहले, एक जांच की जाती है - शायद डेटा स्रोत WriterTo इंटरफ़ेस को लागू करता है, और इस अतिरिक्त बफर की आवश्यकता नहीं है?

यदि ऐसा नहीं होता है, तो हम जांचते हैं: शायद लेखक ने इस मध्यस्थ के बिना कनेक्ट करने के लिए ReaderFrom को लागू किया है? यदि ऐसा नहीं होता है, तो आखिरी उम्मीद बची रहती है: शायद हमें किसी तरह का रिलैक्स्ड बफर दिया गया था जिसे हम इस्तेमाल कर सकते हैं?

इसी तरह io.Copy काम करता है।

एक मुद्दा है, जो एक अर्ध-प्रस्ताव है, एक अर्ध-बग है - यह स्पष्ट नहीं है कि क्या है। यह डेढ़ साल से लटका हुआ है। ऐसा लगता है: CopyBuffer शब्दार्थ गलत है।

दुर्भाग्य से, इस copyBuffer के लिए कोई हस्ताक्षर नहीं है, लेकिन यह बिल्कुल गैर-निर्यात योग्य विधि जैसा दिखता है।

जब आप एक अतिरिक्त स्थान से बचने की उम्मीद में copyBuffer को कॉल करते हैं, तो वहां किसी प्रकार के स्थानांतरित स्लाइस बाइट को स्थानांतरित करें, निम्न तर्क काम करता है: यदि रीडर या लेखक WriterTo और ReaderFrom इंटरफेस को लागू करता है, तो कोई गारंटी नहीं है कि आप इस स्थान से बचने में सक्षम होंगे। इसे एक प्रस्ताव के रूप में स्वीकार किया गया और गो 2.0 में इसके बारे में सोचने का वादा किया गया। अभी के लिए, आपको बस जानने की जरूरत है।

Io.Pipe के साथ काम करें। पाइपराइडर और पाइपवेटर

एक और मामला: आपको किसी भी तरह रीडर से डेटा प्राप्त करने की आवश्यकता है। सुंदर जीवन का मामला।

कल्पना करें कि आपके पास पहले से ही कुछ डेटा है, वे रीडर इंटरफ़ेस को लागू करते हैं - इसके साथ सब कुछ स्पष्ट है। आपको इस डेटा को संपीड़ित करना होगा और इसे "S3" पर भेजना होगा। क्या
बारीकियाँ है ? .. जिसने कंपेज़ पैकेज में gzip प्रकार के साथ काम किया है, वह जानता है कि gzip'er अपने आप में केवल एक प्रॉक्सी है: यह डेटा को अपने आप में ले लेता है, लेखक इंटरफ़ेस को लागू करता है, यह डेटा लिखता है, कुछ उनके लिए करेगा, और तब मुझे उन्हें कहीं छोड़ना होगा। कंस्ट्रक्टर पर, यह राइटर इंटरफ़ेस का कार्यान्वयन करता है।

तदनुसार, यहां हमें किसी प्रकार के मध्यवर्ती लेखक की आवश्यकता है, जहां हम पहले चरण में पहले से संग्रहीत डेटा को छोड़ देंगे। हमारा अगला कदम इस डेटा को S3 पर अपलोड करना है। और मानक AWS क्लाइंट io.Reader इंटरफ़ेस को डेटा स्रोत के रूप में स्वीकार करता है।

स्लाइड पाइपलाइन को दिखाती है - यह दिखाता है कि यह कैसा दिखता है: हमें रीडर से राइटर तक, राइटर से रीडर तक डेटा को ओवरटेक करने की आवश्यकता है। यह कैसे करना है?

मानक पुस्तकालय में एक अच्छी सुविधा है - io.Pipe। यह दो मान देता है: पाइप राइडर और पाइपविटर। यह जोड़ी अटूट रूप से जुड़ी हुई है। रस्सियों के साथ कप में एक "बेबी फोन" की कल्पना करें: एक कप में बोलने का कोई मतलब नहीं है जबकि कोई दूसरे छोर पर नहीं सुन रहा है ...

यह io.Pipe क्या करता है? यह तब तक नहीं पढ़ेगा जब तक कोई डेटा नहीं लिखता। और इसके विपरीत, वह तब तक कुछ भी नहीं लिखेगा जब तक कि कोई इस डेटा को दूसरे छोर पर नहीं पढ़ता। यहां एक उदाहरण कार्यान्वयन है:

हम यहां भी ऐसा ही करेंगे। हम robot.txt फ़ाइल पढ़ेंगे, जिसे पहले पढ़ा गया था, हम इसे अपने gzip का उपयोग करके संपीड़ित करेंगे और इसे S3 में भेजेंगे।

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

इस उदाहरण को दूसरे तरीके से हल किया जा सकता है। यदि आप किसी भी कार्यान्वयन का उपयोग करते हैं जो रीडर और लेखक दोनों को लागू करता है। आप पहले इसमें डेटा लिखेंगे, और फिर उन्हें पढ़ेंगे।
यह io.Pipe के साथ काम करने का एक स्पष्ट प्रदर्शन था।

अन्य कार्यान्वयन

वह मूल रूप से मेरे लिए ही है। हम दिलचस्प कार्यान्वयन पर आते हैं जिसके बारे में मैं बात करना चाहूंगा।

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

एक और कार्यान्वयन लिमियो कहा जाता है। यह आपको घटाव के लिए एक सीमा निर्धारित करने की अनुमति देता है। आप प्रति सेकंड बाइट्स में गति सेट कर सकते हैं जिस पर आपके रीडर को पढ़ने की आवश्यकता है।

एक और दिलचस्प कार्यान्वयन सिर्फ पढ़ने की प्रगति का एक दृश्य है - प्रगति बार (कुछ दोस्त से)। इसे आयपरोग कहा जाता है।

मैंने यह सब क्यों कहा? मुझे इससे क्या मतलब था?

यदि आपको अचानक रीडर और राइटर इंटरफेस को लागू करने की आवश्यकता है, तो इसे सही करें। अभी तक एक भी निर्णय नहीं हुआ है जो कार्यान्वयन के लिए जिम्मेदार है - हम यह मानेंगे कि हर कोई अनुबंध पर भरोसा करता है। अतः आपको इसे त्रुटिहीन रूप से पालन करने की आवश्यकता है।
यदि आपका मामला एक रिपोज्ड बफर के साथ काम कर रहा है, तो ReaderFrom और WriterTo इंटरफेस के बारे में मत भूलना।
यदि आप एक मृत अंत में हैं और आपको उदाहरणों की आवश्यकता है - मानक पुस्तकालय देखें, कई शांत कार्यान्वयन हैं जिन पर आप भरोसा कर सकते हैं। वहां प्रलेखन है।
यदि कोई चीज आपके लिए पूरी तरह से समझ से बाहर है, तो मुद्दों को लिखने के लिए स्वतंत्र महसूस करें। वहाँ के लोग पर्याप्त हैं, जल्दी से जवाब देते हैं, बहुत विनम्रता से और सक्षम रूप से आपकी मदद करते हैं।

वह सब मेरे लिए है आने के लिए शुक्रिया!

प्रशन

दर्शकों से प्रश्न (बी): - मेरे पास एक सरल प्रश्न है, मुझे लगता है। कृपया हमें जीवन से कुछ उपयोग-मामलों के बारे में बताएं: जिनका उपयोग किया गया था और क्यों? आपने कहा था कि पाठक / लेखक उस लंबाई को वापस करता है जो उसने पढ़ी है। क्या आपने कभी इसके साथ कोई समस्या अनुभव की है; आपने पढ़ने की मांग कब की (रीडऑल मौजूद नहीं है), लेकिन कुछ काम नहीं किया?

SA: - मुझे ईमानदारी से स्वीकार करना चाहिए कि मेरे पास ऐसे मामले कभी नहीं थे, क्योंकि मैंने हमेशा मानक पुस्तकालय के कार्यान्वयन के साथ काम किया। लेकिन काल्पनिक रूप से, ऐसी स्थिति, निश्चित रूप से, संभव है। विशिष्ट मामलों के लिए, हम अक्सर बहुपरत पाइप एकत्र करते हैं, और यदि आप काल्पनिक रूप से इस तरह के बग की अनुमति देते हैं, तो पूरा पाइप गिर जाएगा ...

:- यह काफी बग नहीं है। चलिए फिर आपको मेरे छोटे से अनुभव के बारे में बताता हूं। मुझे Booking.com के साथ एक समस्या थी: उन्होंने मेरे द्वारा लिखे गए ड्राइवर का उपयोग किया, और उन्हें एक समस्या थी - कुछ काम नहीं कर रहा था। एक मानक बाइनरी प्रोटोकॉल है जो हमने किया था; स्थानीय रूप से, सब कुछ अच्छा काम करता है, हर कोई ठीक है, लेकिन यह पता चला है कि डेटा सेंटर के साथ उनका बहुत बुरा नेटवर्क है। तब रीडर ने वास्तव में सब कुछ वापस नहीं किया (खराब नेटवर्क कार्ड, कुछ और)।

सीए: - लेकिन अगर उसने सब कुछ वापस नहीं किया है, तो उसे अंत (अंत) का संकेत नहीं लौटना चाहिए था, और ग्राहक को फिर से आना चाहिए। वर्णित अनुबंध के तहत, रीडर को नहीं होना चाहिए ... चलो बस यह कहें कि रीडर, निश्चित रूप से यह तय करता है कि वह कब आना चाहता है, जब वह नहीं चाहता है, हालांकि, अगर वह सब कुछ पढ़ना चाहता है, तो उसे ईओएफ के लिए इंतजार करना होगा।

एटी:"लेकिन यह ठीक कनेक्शन के कारण है।" यह वही समस्या है जो मानक शुद्ध पैकेज में हुई थी।

CA: - और उसने EOF लौटाया?

Q: - उसने सब कुछ वापस नहीं किया - उसने बस सब कुछ नहीं पढ़ा। मैंने उससे कहा: "अगले 20 बाइट्स पढ़ें।" वह पढता है। और मैं सब कुछ नहीं पढ़ता हूं।

SA: - हाइपोथेटिक रूप से, यह संभव है, क्योंकि यह सिर्फ एक इंटरफ़ेस है जो संचार प्रोटोकॉल का वर्णन करता है। मामले को देखना और विशेष रूप से अलग करना आवश्यक है। यहां मैं केवल आपको जवाब दे सकता हूं कि सिद्धांत में, ग्राहक को फिर से आना चाहिए था यदि उसे वह सब कुछ नहीं मिला जो वह चाहता था। आपने उसे 20 बाइट्स के एक स्लाइस के लिए कहा, उसने आपके लिए 15 घटा दिए, लेकिन EOF नहीं आया - आपको फिर से जाना चाहिए ...

Q: - इस स्थिति के लिए io.ReadFull है। यह विशेष रूप से अंत तक टुकड़ा पढ़ने के लिए डिज़ाइन किया गया है।

सीए:- हाँ। मैंने ReadFull के बारे में कुछ नहीं कहा।

Q: - यह पूरी तरह से सामान्य स्थिति है जब रीड पूरे स्लाइस में नहीं भरता है। इसके लिए आपको तैयार रहने की जरूरत है।

SA: - यह एक बहुत ही अपेक्षित मामला है!

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

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

Q: - रिपोर्ट के लिए धन्यवाद। दुर्भाग्य से, मुझे Go में कुछ भी पता नहीं है। यदि "घबराहट" हुई है, तो क्या इस जानकारी को बाधित करने और शुक्रवार रात को समस्याओं से बचने के लिए क्या, कहाँ, कैसे पक्षपाती होना है, इस पर जानकारी प्राप्त करने का कोई तरीका है?

सीए: - हां। पुनर्प्राप्त तंत्र आपको एक घबराहट "पकड़ने" और गिरने, अपेक्षाकृत बोलने के बिना बाहर लाने की अनुमति देता है।

एटी:- लेखक और पाठक के कार्यान्वयन का उपयोग करने के लिए आपकी सिफारिशें उन त्रुटियों के अनुरूप हैं जो वेब सॉकेट्स को लागू करते समय वापस कर दी जाती हैं। मैंने एक ठोस उदाहरण नहीं दिया, लेकिन क्या हमेशा वहाँ इस्तेमाल होने वाली फ़ाइल का अंत होता है? जहां तक मुझे याद है, संदेश कुछ अन्य अर्थों के साथ समाप्त होता है ...

SA: - यह एक अच्छा सवाल है, क्योंकि मेरे पास जवाब देने के लिए कुछ भी नहीं है। देखना चाहिए! यदि ईओएफ नहीं आता है, तो ग्राहक, यदि वह सब कुछ प्राप्त करना चाहता है, तो उसे फिर से जाना चाहिए।

Q: - पाइप कितने समय में इकट्ठा होने में सक्षम था? क्या कोई आंतरिक विश्वास है कि पाइप पांच से अधिक प्रतिभागियों को इकट्ठा करने के लायक नहीं है, या शाखाओं के साथ? आपने कब तक इन पाइपों (पढ़ें, लिखें) से एक पेड़ बनाने का प्रबंधन किया?

सीए:- मेरे व्यवहार में, लगभग पांच लगातार कॉल इष्टतम हैं, क्योंकि यह डिबग करना कठिन है, ध्यान रखें कि क्या बहता है और कहां जाता है। सुंदर शाखा संरचना प्राप्त की है। लेकिन मैं कहीं 5-7 अधिकतम कहूंगा।

Q: - 5-7 - यह किस स्थिति में है?

SA: - यह पढ़ रहा है, उदाहरण के लिए, कुछ डेटा। आपको प्रतिज्ञा करने की आवश्यकता है, और जो आप लॉग इन करते हैं, आपको ट्रिम करने की आवश्यकता है। प्रतिज्ञा की - फिर आप इस डेटा को पढ़ते हैं - आपको इसे कुछ स्टोरेज (अच्छी तरह से, काल्पनिक रूप से) में वापस भेजने की आवश्यकता है। किसी भी स्टोरेज में जो राइटर इंटरफ़ेस लागू करता है। इस पाइप के साथ, 5-6 चरण होते हैं, हालांकि एक कदम पर यह अभी भी शाखा से दूर है, और आप रीडर के साथ काम करना जारी रखते हैं।

एटी:- बिगिनर तरीके के अनुसार, आपके पास एक दिलचस्प स्लाइड थी। क्या आप अन्य 2-3 दिलचस्प बिंदुओं को इंगित कर सकते हैं जो वहां थे, लेकिन अब उन्हें नहीं करना बेहतर है, लेकिन अब इसे अलग तरह से करना है?

SA: - उस स्लाइड के साथ, मैं वास्तव में यह दिखाना चाहता था कि रीडर को पढ़ने की आवश्यकता के बिना इसे कैसे किया जाए। इसने मेरे दिमाग को कभी नहीं पार किया कि शुरुआती रास्ता जैसा कुछ ... यह शायद मुख्य गलती है, मुख्य पैटर्न जिसे पाठकों द्वारा काम करते समय टाला जाना चाहिए।
प्रस्तुतकर्ता: - मैं अपने आप से जोड़ूंगा कि शुरुआत के लिए io पैकेज के सभी दस्तावेज़ीकरणों को पढ़ना बहुत महत्वपूर्ण है, सभी इंटरफेस जो वहां हैं, और उन्हें समझें। क्योंकि वास्तव में उनमें से बहुत से हैं, और आप अक्सर अपने खुद के कुछ करना शुरू करते हैं, हालांकि यह पहले से ही वहां मौजूद है और सही तरीके से लागू किया गया है ("सही" - सभी विशेषताओं को ध्यान में रखते हुए)।
नेता का सवाल: - आगे कैसे जीना है?

CA: - अच्छा सवाल! मैंने यह बताने का वादा किया कि क्या हमारे पास समय है। बग की चर्चा के परिणामस्वरूप, LimitedReader निम्नलिखित निर्णय के साथ आया: कुछ अर्थों में रीडर-कंडोम बनाने के लिए, जो बाहरी खतरों से बचाता है, कुछ रीडर को लपेटें जिन्हें आप भरोसा नहीं करते हैं - किसी भी संक्रमण को आपके सिस्टम में प्रवेश करने से रोकने के लिए।

और इस रीडर में, आप उन सभी चेक को लागू करते हैं जो आप नहीं कर सकते हैं: उदाहरण के लिए, निगेटिव रीडिंग, बाइट्स की संख्या के साथ प्रयोग (मान लीजिए कि आपने 10 बाइट्स का एक स्लाइस भेजा है, और आपको 15 वापस मिले - इस पर कैसे प्रतिक्रिया दें?) ... इस में पाठक और आप इस तरह के चेक का एक सेट लागू कर सकते हैं। मैंने कहा: "हो सकता है कि हम मानक पुस्तकालय में जोड़ें, क्योंकि यह सभी के लिए उपयोगी होगा"?

मुझे जवाब दिया गया था कि इसमें कोई समझदारी नहीं है - यह एक साधारण बात है कि आप खुद को लागू कर सकते हैं। सब। हम पर रहते हैं। हमें कॉन्ट्रैक्ट वालों पर भरोसा है। लेकिन मुझे भरोसा नहीं होगा।

Q: - जब हम रीडर्स, राइटर्स के साथ काम करते हैं और एक गज़िप "बम" में चलने का अवसर होता है ... हम रीडअल्ल और राइटएल स्ट्रीम पर कितना भरोसा करते हैं? या, फिर भी, बफर रीडिंग को लागू करें और केवल बफर के साथ काम करें?

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

विज्ञापन का एक सा :)

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या $ 4.99 से डेवलपर्स के लिए अपने दोस्तों के क्लाउड-आधारित VPS की अनुशंसा करके हमें समर्थन दें, आपके द्वारा आविष्कार किया गया एंट्री-लेवल सर्वर का एक अनूठा एनालॉग: VPS (KVM) E5-2697 3 (6 करोड़) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है!डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग सी?

स्टास अफानसैव। जूनो। Io.Reader / io.Writer पर आधारित पाइपलाइन। भाग 2