अतुल्यकालिक व्यापार तर्क इन दिनों

संक्षेप में:

• प्रमाण पहले से ही C ++ , JS और PHP में लागू है , जावा के लिए उपयुक्त है।
• कोराउटाइन और प्रोमिस की तुलना में तेज़ , अधिक सुविधाएँ।
• इसके लिए एक अलग सॉफ्टवेयर स्टैक की आवश्यकता नहीं है।
• सभी सुरक्षा और डीबगिंग टूल से मित्रता करता है।
• यह किसी भी वास्तुकला पर काम करता है और विशेष संकलक झंडे की आवश्यकता नहीं होती है।

• पीछे देखो
• FutoIn AsyncSteps - कोरआउट के लिए एक विकल्प
• नंबरों को

पीछे देखो

कंप्यूटर के भोर में, इनपुट-आउटपुट पर अवरोध के साथ एक एकल नियंत्रण प्रवाह था। फिर इसमें लोहे की रुकावट डाली गई। अब आप प्रभावी रूप से धीमी और अप्रत्याशित उपकरणों का उपयोग कर सकते हैं।

लोहे की क्षमताओं की वृद्धि और इसकी कम उपलब्धता के साथ, कई कार्यों को एक साथ करना आवश्यक हो गया, जो हार्डवेयर समर्थन प्रदान करते थे। इसलिए संकेतों के रूप में लोहे से अमूर्त व्यवधान के साथ पृथक प्रक्रियाएं थीं।

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

प्रक्रियाओं और यहां तक ​​कि विभिन्न मशीनों के बीच संचार के लिए, वादा / भविष्य अमूर्त 40 + साल पहले प्रस्तावित किया गया था।

उपयोगकर्ता इंटरफेस और वर्तमान में हास्यास्पद 10K क्लाइंट समस्या ने इवेंट लूप, रिएक्टर और प्रॉक्टर के दृष्टिकोण को आगे बढ़ाया है, जो स्पष्ट, सुसंगत व्यावसायिक तर्क की तुलना में अधिक घटना-उन्मुख हैं।

अंत में, हम आधुनिक कोरटाइन (कोरटाइन) के पास आए, जो कि तत्संबंधी तकनीकी सीमाओं और नियंत्रण के नियतात्मक हस्तांतरण के साथ ऊपर वर्णित सार के ऊपर प्रवाह का एक अनुकरण है।

घटनाओं, परिणामों और अपवादों को व्यक्त करने के लिए, वे सभी वादा / भविष्य की एक ही अवधारणा पर लौट आए। कुछ कार्यालयों ने थोड़ा अलग नाम देने का फैसला किया - "कार्य"।

अंत में, उन्होंने सब कुछ एक सुंदर async/await पैकेज में छिपा दिया, जिसे तकनीक के आधार पर संकलक या अनुवादक समर्थन की आवश्यकता होती है।

वर्तमान अतुल्यकालिक व्यापार तर्क स्थितियों के साथ समस्याएं

केवल coroutines और Promise पर विचार करें, async/await साथ सजाया गया, जैसा कि पुराने दृष्टिकोणों में समस्याओं का अस्तित्व ही विकास प्रक्रिया की पुष्टि करता है।

ये दोनों शब्द समान नहीं हैं। उदाहरण के लिए, ईसीएमएस्क्रिप्ट में कोई कोरटाइन नहीं हैं, लेकिन Promise का उपयोग करने के लिए सिंटैक्टिक राहत है, जो बदले में केवल कॉलबैक नरक के साथ काम का आयोजन करता है। वास्तव में, V8 जैसे स्क्रिप्टिंग इंजन आगे बढ़ते हैं और शुद्ध async/await कार्यों और कॉल के लिए विशेष अनुकूलन करते हैं।

विशेषज्ञ co_async/co_await कि यह संसाधन पर C ++ 17 में नहीं आया है, लेकिन सॉफ़्टवेयर की विशालकाय कोराउटीन से दबाव मानक रूप में उनके रूप में दिखाई दे सकता है। इस बीच, पारंपरिक रूप से मान्यता प्राप्त समाधान Boost.Context , Boost.Fiber और Boost.Coroutine2 है ।

जावा में, भाषा के स्तर पर अभी भी कोई async/await नहीं है, लेकिन EA Async जैसे समाधान हैं, जो Boost.Context की तरह, JVM और कोड बाइट के प्रत्येक संस्करण के लिए अनुकूलित किए जाने की आवश्यकता है।

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

लेखक की राय: नंगे-धातु कोरटाइन खतरनाक हैं

व्यक्तिगत रूप से, लेखक के पास गतिशील भाषाओं में कोरटाइन के खिलाफ बहुत कम है, लेकिन वह मशीन कोड के स्तर पर स्टैक के साथ किसी भी छेड़खानी से बेहद सावधान है।

कुछ बिंदु:

1. ढेर की आवश्यकता:
   
   • ढेर पर ढेर के कई नुकसान हैं: अतिप्रवाह के समय पर निर्धारण की समस्याएं, पड़ोसियों द्वारा क्षति और अन्य विश्वसनीयता / सुरक्षा समस्याएं,
   • एक सुरक्षित स्टैक के लिए कम से कम एक पृष्ठ भौतिक मेमोरी, एक सशर्त पृष्ठ और प्रत्येक कॉल के लिए अतिरिक्त ओवरहेड को async फ़ंक्शंस की आवश्यकता होती है: 4 + KB (न्यूनतम) + बढ़ी हुई सिस्टम सीमाएँ,
   • अंततः, यह हो सकता है कि स्टैक के लिए आवंटित मेमोरी का एक महत्वपूर्ण हिस्सा कोरटाउन डाउनटाइम के दौरान उपयोग नहीं किया जाता है।
2. कोरटाइन्स की स्थिति को बचाने, पुनर्स्थापित करने और हटाने का एक जटिल तर्क लागू करना आवश्यक है:
   
   • प्रोसेसर आर्किटेक्चर (यहां तक ​​कि मॉडल) और बाइनरी इंटरफेस (एबीआई) के हर मामले के लिए : उदाहरण ,
   • नई या वैकल्पिक वास्तुकला सुविधाएँ संभावित अव्यक्त समस्याओं (उदाहरण के लिए, इंटेल TSX, ARM सह-प्रोसेसर या MIPS) का परिचय देती हैं।
   • मालिकाना प्रणालियों के कारण अन्य संभावित समस्याएं बंद दस्तावेज (बूस्ट प्रलेखन इसी को संदर्भित करता है)।
3. गतिशील विश्लेषण उपकरण और सामान्य रूप से सुरक्षा के साथ संभावित समस्याएं:
   
   • उदाहरण के लिए, वैल्ग्रिंड के साथ एकीकरण की आवश्यकता होती है, क्योंकि सभी एक ही जम्पिंग स्टैक,
   • एंटीवायरस के लिए बोलना कठिन है, लेकिन शायद वे अतीत में जेवीएम के साथ समस्याओं के उदाहरण पर इसे पसंद नहीं करते हैं,
   • मुझे यकीन है कि नए प्रकार के हमले दिखाई देंगे और कोरटाइन के कार्यान्वयन से जुड़ी कमजोरियां सामने आएंगी।

लेखक की राय: जनरेटर और yield मौलिक बुराई

यह प्रतीत होता है कि तृतीय-पक्ष थीम सीधे तौर पर कॉरआउट्स की अवधारणा और "जारी" संपत्ति से संबंधित है।

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

यदि मामला एक अनंत जनरेटर है, तो इसके कार्यान्वयन का तर्क प्राथमिक है। एक अंतहीन चल रहे चक्र को अलग करने के लिए अतिरिक्त तकनीकी कठिनाइयों का निर्माण क्यों करें।

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

वास्तव में, हल की जाने वाली समस्या एक उंगली से प्राप्त की जाती है और प्रारंभिक कार्यान्वयन और दीर्घकालिक समर्थन के लिए अपेक्षाकृत गंभीर प्रयासों की आवश्यकता होती है। इतना कुछ है कि कुछ परियोजनाएं goto पर प्रतिबंध के उदाहरण या व्यक्तिगत उद्योगों में गतिशील मेमोरी आवंटन के उपयोग के बाद मशीन कोड स्तर के कोरआउट के उपयोग पर प्रतिबंध लगा सकती हैं।

लेखकों की राय: ECMAScript का async/await वादा मॉडल अधिक विश्वसनीय है, लेकिन अनुकूलन की आवश्यकता है

कॉरटाइन्स को जारी रखने के विपरीत, इस मॉडल में कोड के टुकड़ों को गुप्त कार्यों के रूप में डिज़ाइन किए गए गैर-रुकावट वाले ब्लॉक में विभाजित किया गया है। C ++ में, यह स्मृति प्रबंधन की ख़ासियत के कारण पूरी तरह से उपयुक्त नहीं है, एक उदाहरण:

 struct SomeObject { using Value = std::vector<int>; Promise funcPromise() { return Promise.resolved(value_); } void funcCallback(std::function<void()> &&cb, const Value& val) { somehow_call_later(cb); } Value value_; }; Promise example() { SomeObject some_obj; return some_obj.funcPromise() .catch([](const std::exception &e){ // ... }) .then([&](SomeObject::value &&val){ return Promise([&](Resolve&& resolve, Reject&&){ some_obj.funcCallback(resolve, val); }); }); } 

सबसे पहले, some_obj नष्ट हो जाएगा जब example() बाहर some_obj example() और लैम्ब्डा फ़ंक्शन को कॉल करने से पहले।

दूसरे, लैम्ब्डा चर या संदर्भों को कैप्चर करने के साथ कार्य करते हैं और ऑब्जेक्ट्स गुप्त रूप से कॉपी / मूव जोड़ते हैं, जो बड़ी संख्या में कैप्चर के साथ प्रदर्शन को नकारात्मक रूप से प्रभावित कर सकते हैं और सामान्य std::function में टाइप इरेज के दौरान हीप पर मेमोरी आवंटित करने की आवश्यकता होती है।

तीसरी बात, व्यावसायिक तर्क के लगातार निष्पादन के बजाय, Promise इंटरफेस की कल्पना "परिणाम" के वादे पर की गई थी।

एक योजनाबद्ध नहीं इष्टतम समाधान कुछ इस तरह लग सकता है:

 Promise example() { struct LocalContext { SomeObject some_obj; }; auto ctx = std::make_shared<LocalContext>(); return some_obj.funcPromise() .catch([](const std::exception &e){ // ... }) .then([ctx](SomeObject::Value &&val){ struct LocalContext2 { LocalContext2(std::shared_ptr<LocalContext> &&ctx, SomeObject::Value &&val) : ctx(ctx), val(val) {} std::shared_ptr<LocalContext> ctx; SomeObject::Value val; }; auto ctx2 = std::make_shared<LocalContext2>( std::move(ctx), std::forward<SomeObject::Value>(val) ); return Promise([ctx2](Resolve&& resolve, Reject&&){ ctx2->ctx->some_obj.funcCallback([ctx2, resolve](){ resolve(); }, val); }); }); } 

नोट: std::move बजाय std::move std::shared_ptr कई लैम्ब्डा में स्थानांतरित करने में असमर्थता और उनके आकार के विकास के कारण उपयुक्त नहीं है।

async/await अतुल्यकालिक भयावहता एक सुपाच्य स्थिति में आती है:

 async void example() { SomeObject some_obj; try { SomeObject::Value val = await some_obj.func(); } catch (const std::exception& e) ( // ... } // Capture "async context" return Promise([async](Resolve&& resolve, Reject&&){ some_obj.funcCallback([async](){ resolve(); }, val); }); } 

लेखक की राय: कोरटाइन प्लानर एक हलचल है

कुछ आलोचक एक अनुसूचक की कमी और प्रोसेसर के संसाधनों के "बेईमान" उपयोग को एक समस्या कहते हैं। शायद अधिक गंभीर समस्या डेटा स्थानीयता और प्रोसेसर कैश का कुशल उपयोग है।

पहली समस्या पर: व्यक्तिगत coroutines के स्तर पर प्राथमिकता एक बड़े उपरि की तरह लगती है। इसके बजाय, वे एक विशिष्ट एकीकृत कार्य के लिए सामान्य रूप से संचालित किए जा सकते हैं। ट्रैफिक फ्लो यही करता है।

यह अपने स्वयं के "लोहे" धागे और ओएस स्तर पर योजना के साथ इवेंट लूप के अलग-अलग उदाहरणों को बनाने के द्वारा संभव है। दूसरा विकल्प प्रतिस्पर्धा और / या प्रदर्शन के संदर्भ में एक अपेक्षाकृत आदिम (म्यूटेक्स, थ्रॉटल) आदिम के साथ कोरआउट को सिंक्रनाइज़ करना है।

एसिंक्रोनस प्रोग्रामिंग प्रोसेसर संसाधनों को रबरयुक्त नहीं बनाती है और कुल निष्पादन समय पर एक साथ संसाधित कार्यों और सीमाओं की संख्या पर बिल्कुल सामान्य प्रतिबंध की आवश्यकता होती है।

एक coroutine पर लंबे समय तक अवरुद्ध होने से बचाने के लिए कॉलबैक के साथ समान उपायों की आवश्यकता होती है - ब्लॉकिंग कॉल और लंबी डेटा प्रोसेसिंग चक्र से बचने के लिए।

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

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

लेखक की राय: मॉडरेशन में सब कुछ अच्छा है

आधुनिक ऑपरेटिंग सिस्टम में थ्रेड्स की उपस्थिति व्यक्तिगत प्रक्रियाओं के उपयोग को नकारती नहीं है। साथ ही, इवेंट लूप में बड़ी संख्या में क्लाइंट्स को संसाधित करना अन्य आवश्यकताओं के लिए पृथक "आयरन" थ्रेड्स के उपयोग को नकारता नहीं है।

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

FutoIn AsyncSteps - कोरआउट के लिए एक विकल्प

हम ECMAScript (जावास्क्रिप्ट) वादा प्रकार के अनुसार पहले से ही स्थापित इवेंट लूप पैटर्न और कॉलबैक योजनाओं के संगठन के आधार के रूप में लेते हैं।

निष्पादन योजना के संदर्भ में, हम इवेंट लूप से निम्नलिखित गतिविधियों में रुचि रखते हैं:

1. Handle immediate(callack) एक साफ कॉल स्टैक की आवश्यकता है।
2. आस्थगित कॉलबैक Handle deferred(delay, callback) ।
3. कॉलबैक handle.cancel() रद्द करें handle.cancel() ।

इसलिए हमें AsyncTool नाम का एक इंटरफ़ेस मिलता है, जिसे कई तरीकों से लागू किया जा सकता है, जिसमें मौजूदा सिद्ध घटनाक्रम के शीर्ष पर भी शामिल है। व्यावसायिक तर्क लिखने में उनका कोई सीधा संबंध नहीं है, इसलिए हम आगे के विवरण में नहीं जाएंगे।

चरणों का पेड़:

AsyncSteps अवधारणा में, सिंक्रोनस चरणों के एक सार पेड़ को पंक्तिबद्ध किया गया है और निर्माण अनुक्रम में गहराई से जाकर निष्पादित किया गया है। प्रत्येक गहरा स्तर के चरण गतिशील रूप से सेट होते हैं जैसे कि एक मार्ग पूरा हो गया है।

सभी इंटरैक्शन एक एकल AsyncSteps इंटरफ़ेस के माध्यम से AsyncSteps है, जो कि कन्वेंशन द्वारा, प्रत्येक चरण के लिए पहले पैरामीटर के रूप में पारित किया जाता है। सम्मेलन द्वारा, पैरामीटर नाम asi या पदावनत as । यह दृष्टिकोण आपको प्लगइन्स और पुस्तकालयों में एक विशिष्ट कार्यान्वयन और लेखन व्यवसाय तर्क के बीच संबंध को लगभग पूरी तरह से तोड़ने की अनुमति देता है।

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

सार उदाहरण:

  asi.add( // Level 0 step 1 func( asi ){ print( "Level 0 func" ) asi.add( // Level 1 step 1 func( asi ){ print( "Level 1 func" ) asi.error( "MyError" ) }, onerror( asi, error ){ // Level 1 step 1 catch print( "Level 1 onerror: " + error ) asi.error( "NewError" ) } ) }, onerror( asi, error ){ // Level 0 step 1 catch print( "Level 0 onerror: " + error ) if ( error strequal "NewError" ) { asi.success( "Prm", 123, [1, 2, 3], true) } } ) asi.add( // Level 0 step 2 func( asi, str_param, int_param, array_param ){ print( "Level 0 func2: " + param ) } ) 

निष्पादन परिणाम:

  Level 0 func 1 Level 1 func 1 Level 1 onerror 1: MyError Level 0 onerror 1: NewError Level 0 func 2: Prm 

सिंक में, यह इस तरह दिखेगा:

  str_res, int_res, array_res, bool_res // undefined try { // Level 0 step 1 print( "Level 0 func 1" ) try { // Level 1 step 1 print( "Level 1 func 1" ) throw "MyError" } catch( error ){ // Level 1 step 1 catch print( "Level 1 onerror 1: " + error ) throw "NewError" } } catch( error ){ // Level 0 step 1 catch print( "Level 0 onerror 1: " + error ) if ( error strequal "NewError" ) { str_res = "Prm" int_res = 123 array_res = [1, 2, 3] bool_res = true } else { re-throw } } { // Level 0 step 2 print( "Level 0 func 2: " + str_res ) } 

पारंपरिक तुल्यकालिक कोड की अधिकतम नकल तुरंत दिखाई देती है, जिसे पठनीयता में मदद करनी चाहिए।

व्यावसायिक तर्क के दृष्टिकोण से, आवश्यकताओं की एक बड़ी गांठ समय के साथ बढ़ती है, लेकिन हम इसे आसानी से समझे जाने वाले भागों में विभाजित कर सकते हैं। नीचे वर्णित है, चार साल से चल रहे अभ्यास का परिणाम है।

कोर रनटाइम एपीआई:

1. add(func[, onerror]) - try-catch नकल।
2. success([args...]) - सफल समापन का एक स्पष्ट संकेत:
   
   • डिफ़ॉल्ट रूप से निहित
   • अगले चरण के लिए परिणाम पारित कर सकते हैं।
3. error(code[, reason) - एक त्रुटि के साथ निष्पादन की रुकावट:
   
   • code - एक स्ट्रिंग प्रकार है जो बेहतर ढंग से माइक्रोसॉफ़्ट वास्तुकला में नेटवर्क प्रोटोकॉल के साथ एकीकृत करता है,
   • reason - एक व्यक्ति के लिए एक मनमाना स्पष्टीकरण।
4. state() - थ्रेड लोकल स्टोरेज का एक एनालॉग। पूर्वनिर्धारित साहचर्य कुंजी:
   
   • error_info - किसी व्यक्ति के लिए अंतिम त्रुटि का स्पष्टीकरण,
   • last_exception - अंतिम अपवाद की वस्तु के लिए सूचक,
   • async_stack - अतुल्यकालिक कॉल का एक ढेर async_stack तकनीक की अनुमति है,
   • बाकी उपयोगकर्ता द्वारा निर्धारित किया गया है।

पिछला उदाहरण पहले से ही वास्तविक C ++ कोड और कुछ अतिरिक्त सुविधाओं के साथ है:

 #include <futoin/iasyncsteps.hpp> using namespace futoin; void some_api(IAsyncSteps& asi) { asi.add( [](IAsyncSteps& asi) { std::cout << "Level 0 func 1" << std::endl; asi.add( [](IAsyncSteps& asi) { std::cout << "Level 1 func 1" << std::endl; asi.error("MyError"); }, [](IAsyncSteps& asi, ErrorCode code) { std::cout << "Level 1 onerror 1: " << code << std::endl; asi.error("NewError", "Human-readable description"); } ); }, [](IAsyncSteps& asi, ErrorCode code) { std::cout << "Level 0 onerror 1: " << code << std::endl; if (code == "NewError") { // Human-readable error info assert(asi.state().error_info == "Human-readable description"); // Last exception thrown is also available in state std::exception_ptr e = asi.state().last_exception; // NOTE: smart conversion of "const char*" asi.success("Prm", 123, std::vector<int>({1, 2, 3}, true)); } } ); asi.add( [](IAsyncSteps& asi, const futoin::string& str_res, int int_res, std::vector<int>&& arr_res) { std::cout << "Level 0 func 2: " << str_res << std::endl; } ); } 

लूप बनाने के लिए एपीआई:

1. loop( func, [, label] ) - एक असीम दोहराव वाले शरीर के साथ कदम।
2. forEach( map|list, func [, label] ) - संग्रह वस्तु का चरण-पुनरावृत्ति।
3. repeat( count, func [, label] ) - चरण-पुनरावृत्ति निर्दिष्ट समय की संख्या।
4. break( [label] ) पारंपरिक लूप व्यवधान का एक एनालॉग है।
5. continue( [label] ) एक नए पुनरावृत्ति के साथ पारंपरिक लूप निरंतरता का एक एनालॉग है।

विनिर्देश आरक्षित शब्दों के साथ संघर्ष के मामले में वैकल्पिक नाम breakLoop , continueLoop और अन्य प्रदान करता है।

C ++ उदाहरण:

  asi.loop([](IAsyncSteps& asi) { // infinite loop asi.breakLoop(); }); asi.repeat(10, [](IAsyncSteps& asi, size_t i) { // range loop from i=0 till i=9 (inclusive) asi.continueLoop(); }); asi.forEach( std::vector<int>{1, 2, 3}, [](IAsyncSteps& asi, size_t i, int v) { // Iteration of vector-like and list-like objects }); asi.forEach( std::list<futoin::string>{"1", "2", "3"}, [](IAsyncSteps& asi, size_t i, const futoin::string& v) { // Iteration of vector-like and list-like objects }); asi.forEach( std::map<futoin::string, futoin::string>(), [](IAsyncSteps& asi, const futoin::string& key, const futoin::string& v) { // Iteration of map-like objects }); std::map<std::string, futoin::string> non_const_map; asi.forEach( non_const_map, [](IAsyncSteps& asi, const std::string& key, futoin::string& v) { // Iteration of map-like objects, note the value reference type }); 

बाहरी घटनाओं के साथ एकीकरण के लिए एपीआई:

1. setTimeout( timeout_ms ) - एक Timeout बाद Timeout त्रुटि फेंकता है यदि चरण और उसके उपप्रकार ने निष्पादन पूरा नहीं किया है।
2. setCancel( handler ) - रद्द हैंडलर को सेट करता है, जिसे थ्रेड को पूरी तरह से रद्द करने और त्रुटि प्रसंस्करण के दौरान एसिंक्रोनस चरणों के ढेर का विस्तार होने पर कहा जाता है।
3. प्रतीक्षा बाह्य waitExternal() - एक बाहरी घटना के लिए एक सरल प्रतीक्षा।
   
   • नोट: यह केवल कचरा बीनने वाली प्रौद्योगिकियों में उपयोग करने के लिए सुरक्षित है।

इनमें से किसी भी कार्य के लिए एक कॉल success() लिए एक स्पष्ट कॉल करता है।

C ++ उदाहरण:

  asi.add([](IAsyncSteps& asi) { auto handle = schedule_external_callback([&](bool err) { if (err) { try { asi.error("ExternalError"); } catch (...) { // pass } } else { asi.success(); } }); asi.setCancel([=](IAsyncSteps& asi) { external_cancel(handle); }); }); asi.add( [](IAsyncSteps& asi) { // Raises Timeout error after specified period asi.setTimeout(std::chrono::seconds{10}); asi.loop([](IAsyncSteps& asi) { // infinite loop }); }, [](IAsyncSteps& asi, ErrorCode code) { if (code == futoin::errors::Timeout) { asi(); } }); 

ECMAScript उदाहरण:

 asi.add( (asi) => { asi.waitExternal(); // disable implicit success() some_obj.read( (err, data) => { if (!asi.state) { // ignore as AsyncSteps execution got canceled } else if (err) { try { asi.error( 'IOError', err ); } catch (_) { // ignore error thrown as there are no // AsyncSteps frames on stack. } } else { asi.success( data ); } } ); } ); 

भविष्य / वादा एकीकरण एपीआई:

1. await(promise_future[, on_error]) - एक कदम के रूप में भविष्य / वादा करने की प्रतीक्षा कर रहा है।
2. promise() - निष्पादन के पूरे प्रवाह को फ्यूचर / प्रॉमिस में बदल देता है, जिसका उपयोग execute() बजाय किया जाता है।

C ++ उदाहरण:

  [](IAsyncSteps& asi) { // Proper way to create new AsyncSteps instances // without hard dependency on implementation. auto new_steps = asi.newInstance(); new_steps->add([](IAsyncSteps& asi) {}); // Can be called outside of AsyncSteps event loop // new_steps.promise().wait(); // or // new_steps.promise<int>().get(); // Proper way to wait for standard std::future asi.await(new_steps->promise()); // Ensure instance lifetime asi.state()["some_obj"] = std::move(new_steps); }; 

व्यापार तर्क प्रवाह नियंत्रण एपीआई:

1. AsyncSteps(AsyncTool&) एक कंस्ट्रक्टर है जो किसी विशिष्ट ईवेंट लूप पर निष्पादन का एक धागा बांधता है।
2. execute() - निष्पादन थ्रेड प्रारंभ करता है।
3. cancel() - निष्पादन के धागे को रद्द करता है।

एक विशिष्ट इंटरफ़ेस कार्यान्वयन पहले से ही यहां आवश्यक है।

C ++ उदाहरण:

 #include <futoin/ri/asyncsteps.hpp> #include <futoin/ri/asynctool.hpp> void example() { futoin::ri::AsyncTool at; futoin::ri::AsyncSteps asi{at}; asi.loop([&](futoin::IAsyncSteps &asi){ // Some infinite loop logic }); asi.execute(); std::this_thread::sleep_for(std::chrono::seconds{10}); asi.cancel(); // called in d-tor by fact } 

अन्य एपीआई:

1. newInstance() - आपको कार्यान्वयन पर प्रत्यक्ष निर्भरता के बिना निष्पादन का एक नया धागा बनाने की अनुमति देता है।
2. sync(object, func, onerror) - समान, लेकिन संबंधित वस्तु के साथ सिंक्रनाइज़ किए गए ऑब्जेक्ट के सापेक्ष सिंक्रनाइज़ेशन।
3. parallel([on_error]) - विशेष add() , जिसके प्रतिस्थापन अलग हैं AsyncSteps धाराएँ:
   
   • सभी थ्रेड्स में सामान्य state() ,
   • सभी बच्चे के पूरा होने पर माता-पिता का निष्पादन जारी रहता है
   • किसी भी बच्चे में एक अनकही त्रुटि तुरंत अन्य सभी बच्चे धागे को रद्द कर देती है।

C ++ उदाहरण:

  #include <futoin/ri/mutex.hpp> using namespace futoin; ri::Mutex mtx_a; void sync_example(IAsyncSteps& asi) { asi.sync(mtx_a, [](IAsyncSteps& asi) { // synchronized section asi.add([](IAsyncSteps& asi) { // inner step in the section // This synchronization is NOOP for already // acquired Mutex. asi.sync(mtx_a, [](IAsyncSteps& asi) { }); }); }); } void parallel_example(IAsyncSteps& asi) { using OrderVector = std::vector<int>; asi.state("order", OrderVector{}); auto& p = asi.parallel([](IAsyncSteps& asi, ErrorCode) { // Overall error handler asi.success(); }); p.add([](IAsyncSteps& asi) { // regular flow asi.state<OrderVector>("order").push_back(1); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(4); }); }); p.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(2); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(5); asi.error("SomeError"); }); }); p.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(3); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(6); }); }); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order"); // 1, 2, 3, 4, 5 }); }; 

तुल्यकालन के लिए मानक आदिम

1. Mutex - डिफ़ॉल्ट रूप से N=1, Q=unlimited द्वारा Q में Q साथ N थ्रेड्स के एक साथ निष्पादन को प्रतिबंधित करता है।
2. Throttle - P में P Q में डिफ़ॉल्ट N=1, P=1s, Q=0 द्वारा Q साथ इनपुट N की संख्या को सीमित करता है।
3. Limiter Mutex और Throttle का एक संयोजन है, जो आमतौर पर बाहरी अनुरोधों को संसाधित करने और लोड के तहत स्थिर संचालन के उद्देश्य के लिए बाहरी प्रणालियों को कॉल करने के इनपुट पर उपयोग किया जाता है।

कतार की सीमाओं को DefenseRejected मामले में, एक DefenseRejected त्रुटि को DefenseRejected , जिसका अर्थ DefenseRejected विवरण से स्पष्ट है।

मुख्य लाभ

AsyncSteps की अवधारणा अपने आप में एक अंत नहीं थी, लेकिन समय-सीमा, रद्द करने और व्यक्तिगत कॉलबैक की समग्र कनेक्टिविटी के संदर्भ में कार्यक्रमों के अधिक नियंत्रित अतुल्यकालिक निष्पादन की आवश्यकता से बाहर पैदा हुई थी। उस समय कोई भी सार्वभौमिक समाधान नहीं है और अब समान कार्यक्षमता प्रदान करते हैं। इसलिए:

FTN12 — .

setCancel() — . , . RAII atexit() .

cancel() — , . SIGTERM pthread_cancel() , .

setTimeout() — . , "Timeout".

— FutoIn AsyncSteps .

— ABI , . Embedded MMU.

Intel Xeon E3-1245v2/DDR1333 Debian Stretch .

:

1. Boost.Fiber protected_fixedsize_stack .
2. Boost.Fiber pooled_fixedsize_stack .
3. FutoIn AsyncSteps .
4. FutoIn AsyncSteps ( FUTOIN_USE_MEMPOOL=false ).
   
   • futoin::IMemPool .
5. FutoIn NitroSteps<> — .
   
   • .

Boost.Fiber :

1. 1 . .
2. 30 . 1 . .
   
   • 30 . mmap()/mprotect() boost::fiber::protected_fixedsize_stack .
   • .
3. 30 . 10 . .
   
   • "" .

"" , .. , . . .

GCC 6.3.0. lang tcmalloc , .

GitHub GitLab .

1.

— .

Boost.Fiber - , pooled_fixedsize_stack , AsyncSteps.

2.

— .

, . , — .

3.

— .

, Boost.Fiber AsyncSteps, NitroSteps.

( RSS)

— .

, Boost.Fiber .

: Node.js

- Promise : + 10 . . 10 . JIT NODE_ENV=production , @futoin/optihelp .

GitHub GitLab . Node.js v8.12.0 v10.11.0, FutoIn CID .

— .

async/await ? , V8 Node.js v10 .

, Promise async/await Node.js Event Loop. ( ), FutoIn AsyncSteps .

AsyncSteps Node.js Event Loop async/await - Node.js v10.

, ++ — . , Node.js 10 .

निष्कर्ष

C++, FutoIn AsyncSteps Boost.Fiber , Boost.Fiber mmap()/mprotect .

, - , . .

FutoIn AsyncSteps JavaScript async/await Node.js v10.

, -, . .

- "" . — API.

निष्कर्ष

, FutoIn AsyncSteps , "" async/await . , . Promise ECMAScript, AsyncSteps "" .

. AsyncSteps NitroSteps .

, - .

Java/JVM — . .

, GitHub / GitLab .