EventMachine ⇒ बाद के प्रसंस्करण के साथ विभिन्न स्रोतों से जानकारी का संग्रह

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

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

EventMachine

gem install eventmachine 

EventMachine वर्ग कम या ज्यादा प्रलेखित है और सरल प्रश्नों से निपटना आसान है। आमतौर पर सब कुछ किसी न किसी तरह से होता है ( EM EventMachine लिए एक उपनाम है):

 begin EM.run do … # -   , , EM.connect (…) #     EM.add_periodic_timer(1) { puts "on tick" } end ensure EM.stop #     ,     end 

आप रिएक्टर शटडाउन पर एक हुक लटका सकते हैं ( EventMachine.add_shutdown_hook {"बाहर निकल रहा है ..."} )। ठीक है, निश्चित रूप से, आप मक्खी पर अतुल्यकालिक कनेक्शन बना सकते हैं। प्रलेखन, मैं दोहराता हूं, है। स्थानों में, यहां तक ​​कि समझदार भी।
लेकिन पर्याप्त थकाऊपन।

परिणामों का संग्रह

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

खोज के माध्यम से गब्बीर सर्वर पर हमें जिस घटक की आवश्यकता है, उसे ढूंढें और उसके साथ संवाद करें

शब्दों में, यह किसी भी तरह से होता है: हम खोज के लिए एक अनुरोध भेजते हैं, हमें घटकों की एक सूची मिलती है, हम इसकी क्षमताओं के लिए प्रत्येक घटक का साक्षात्कार करते हैं। यदि सुविधाओं की सूची में हमारा स्थान है, तो हम आरंभ करते हैं।
यहां यह EventMachine गया है कि EventMachine का उपयोग EventMachine (मैंने वह सब कुछ हटा दिया जो सीधे EM साथ काम करने से संबंधित नहीं है):

 @stream.write_with_handler(disco) do |result| … # iterate thru disco results and wait until all collected EM::Iterator.new(result.items).map proc{ |c, it_disco| … @stream.write_with_handler(info) do |reply| … # iterate thru discoinfo results and wait until all collected, # then switch the parent's iterator EM::Iterator.new(reply.features).map proc{ |f, it_info| it_info.return … }, proc{ |comps| # one more disco item was utilized it_disco.return … } … end … }, proc{ |compss| # yielding # compss.init or smth like that … } end 

Iterators और उनके जादू मानचित्र समारोह हमारे लिए सभी काम करेंगे। अंतिम कोष्ठक (टिप्पणी "उपज") के तहत लंबोदर कोड केवल तभी निष्पादित किया जाएगा जब पाया गया प्रत्येक घटक के लिए सभी डिस्कोइनो एकत्र किया जाता है।

मैं माफी माँगता हूँ अगर यह किसी को स्पष्ट लगता है, लेकिन Google ने मुझे त्वरित समाधान की पेशकश नहीं की, और यहां Fiber साथ उपद्रव शुद्ध नरक में बदल जाता है।