तीसरे दिन, SObjectizer का एक नया संस्करण उपलब्ध हुआ : 5.6.0 । इसकी मुख्य विशेषता पिछली स्थिर शाखा 5.5 के साथ संगतता की अस्वीकृति है, जो साढ़े चार साल के दौरान लगातार विकसित हो रही है।

SObjectizer-5 के संचालन के मूल सिद्धांत समान रहे। संचार, एजेंट, सहयोग और प्रेषणकर्ता अभी भी हमारे साथ हैं। लेकिन कुछ गंभीरता से बदल गया, कुछ आम तौर पर फेंक दिया गया था। इसलिए, केवल SO-5.6.0 लेने और अपने कोड को फिर से जमा करने में विफल हो जाएगा। कुछ को फिर से लिखना होगा। कुछ नया करना होगा।

हमने कई वर्षों तक संगतता का ख्याल क्यों रखा, और फिर सब कुछ लेने और तोड़ने का फैसला किया? और सबसे अच्छी तरह से क्या टूट गया?

मैं इस लेख में इस बारे में बात करने की कोशिश करूंगा।

आपको कुछ तोड़ने की आवश्यकता क्यों थी?

यह इतना आसान है।

अपने विकास के दौरान SObjectizer-5.5 ने मूल रूप से नियोजित नहीं किए गए इतने सारे अलग-अलग और विविध चीजों को अवशोषित किया है, परिणामस्वरूप, इसने अंदर कई बैसाखी और प्रॉप्स का गठन किया है। प्रत्येक नए संस्करण के साथ, SO-5.5 में कुछ नया जोड़ना कठिन और कठिन हो गया। और अंत में, सवाल के लिए "हमें यह सब क्यों चाहिए?" कोई उपयुक्त उत्तर नहीं मिला।

तो पहला कारण एसओबीजेनाइज़र के गिलेट्स की पुनः जटिलता है।

दूसरा कारण यह है कि हम पुराने C ++ कंपाइलर पर ध्यान केंद्रित करते हुए मूर्खतापूर्ण रूप से थक चुके हैं। शाखा 5.5 2014 में शुरू हुई, जब हमारे पास था, अगर मुझसे गलती नहीं हुई, तो जीसीसी-4.8 और एमएसवीएस2013। और इस स्तर पर, हम अभी भी C ++ मानक के समर्थन के स्तर के लिए आवश्यकताओं की पट्टी बनाए रखना जारी रखा।

प्रारंभ में, इसमें हमारा "स्वार्थ" था। इसके अलावा, कुछ समय के लिए हमने सी + + मानक के लिए समर्थन की गुणवत्ता के लिए कम आवश्यकताओं को हमारे "प्रतिस्पर्धी लाभ" के रूप में माना।

लेकिन समय आगे बढ़ता है, "स्वार्थी हित" खत्म हो जाता है। इस तरह के "प्रतिस्पर्धी लाभ" से कुछ लाभ दिखाई नहीं दे रहे हैं। शायद वे होंगे, अगर हम सी ++ 98 के साथ काम करते हैं, तो हम खूनी उद्यम में दिलचस्पी लेंगे। लेकिन उन जैसे खूनी उद्यम, सिद्धांत रूप में, दिलचस्पी नहीं है। इसलिए, खुद को सीमित करने और कुछ नया करने का निर्णय लिया गया। इसलिए हमने इस समय स्थिर का सबसे ताज़ा हिस्सा लिया: C ++ 17।

जाहिर है, हर कोई इस समाधान को पसंद नहीं करेगा, आखिरकार, कई सी ++ 17 के लिए यह अब एक अप्राप्य अग्रणी बढ़त है, जो अभी भी बहुत दूर है।

फिर भी, हमने इस तरह के जोखिम पर फैसला किया। वैसे भी, SObjectizer को लोकप्रिय बनाने की प्रक्रिया तेजी से नहीं चल रही है, इसलिए जब SObjectizer अधिक या कम व्यापक रूप से मांग वाला हो जाता है, तो C ++ 17 अब "अग्रणी बढ़त" नहीं होगा। बल्कि, यह वैसा ही माना जाएगा जैसा कि अब C ++ 11 में है।

सामान्य तौर पर, C ++ 11 के सबसेट का उपयोग करके बैसाखी का निर्माण जारी रखने के बजाय, हमने C ++ 17 का उपयोग करते हुए SObjectizer के आंतरिक रीमेक को गंभीरता से लेने का निर्णय लिया। एक आधार बनाने के लिए जिस पर SObjectizer उत्तरोत्तर अगले चार या पाँच वर्षों में विकसित हो सकता है।

SObjectizer-5.6 में गंभीरता से क्या बदलाव आया है?

अब, आइए संक्षेप में सबसे महत्वपूर्ण परिवर्तनों में से कुछ पर जाएं।

एजेंट सहयोग में अब स्ट्रिंग नाम नहीं हैं

समस्या

शुरुआत से ही, SObjectizer-5 ने मांग की कि प्रत्येक सहयोग का अपना एक विशिष्ट स्ट्रिंग नाम है। यह सुविधा पिछले, चौथे एसओबीजेनाइज़र से पांचवें एसोबिजाइज़र से विरासत में मिली थी।

तदनुसार, SObjectizer को पंजीकृत सहयोग के नामों को संग्रहीत करने की आवश्यकता थी। पंजीकरण में उनकी विशिष्टता की जाँच करें। डेरेगेजेशन, आदि के दौरान नाम से सहयोग के लिए खोजें।

बहुत पहले संस्करणों के बाद से, सोब्जेक्टजर -5 में एक सरल योजना का उपयोग किया गया है: म्यूटेक्स द्वारा संरक्षित पंजीकृत सहकारी समितियों का एक शब्दकोश। सहयोग दर्ज करते समय, म्यूटेक्स पर कब्जा कर लिया जाता है, सहयोग के नाम की विशिष्टता, माता-पिता की उपस्थिति आदि की जाँच की जाती है। जाँच करने के बाद, शब्दकोश को संशोधित किया जाता है, जिसके बाद म्यूटेक्स जारी किया जाता है। इसका मतलब यह है कि यदि एक ही समय में एक ही बार में कई सहकारी समितियों का पंजीकरण / डीरजिस्ट्रेशन शुरू हो जाता है, तो कुछ बिंदुओं पर वे तब तक रुकेंगे और तब तक इंतजार करेंगे जब तक कि कोई एक ऑपरेशन सहकारी शब्दकोश के साथ काम पूरा न कर ले। इस वजह से, सहकारी संचालन अच्छा नहीं हुआ।

यही कारण है कि मैं सहयोग के पंजीकरण की गति के साथ स्थिति में सुधार करने के लिए छुटकारा पाना चाहता था।

निर्णय

इस समस्या को हल करने के दो मुख्य तरीकों पर विचार किया गया।

सबसे पहले, स्ट्रिंग नामों को संग्रहीत करना, लेकिन शब्दकोश को संग्रहीत करने के तरीके को बदलना ताकि सहयोग पंजीकरण ऑपरेशन स्केल हो सके। उदाहरण के लिए, डिक्शनरी शार्डिंग, अर्थात इसे कई टुकड़ों में तोड़ना, जिनमें से प्रत्येक को म्यूटेक्स द्वारा संरक्षित किया जाएगा।

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

परिणामस्वरूप, हमने दूसरी विधि को चुना और सहकारी समितियों के नामकरण को पूरी तरह से छोड़ दिया। अब SObjectizer में coop_handle , यानी ऐसी चीज़ है एक हैंडल जिसकी सामग्री उपयोगकर्ता से छिपी हुई है, लेकिन जिसकी तुलना std::weak_ptr की जा सकती है।

सहयोग दर्ज करते समय coop_handle कूप_हैंडल लौटाया:

 auto coop = env.make_coop(); ... //    . auto coop_id = env.register_coop(std::move(coop)); // . //   coop_id    . 

इस संभाल का उपयोग सहयोग के निपुणता के लिए किया जाना चाहिए:

 auto coop = env.make_coop(); ... //    . auto coop_id = env.register_coop(std::move(coop)); // . //   coop_id    . ... // - . // ,     . //       . env.deregister_coop(coop_id, ...); 

इसके अलावा, माता-पिता-बच्चे के संबंध स्थापित करते समय इस हैंडल का उपयोग किया जाना चाहिए:

 //   . auto parent = env.make_coop(); ... //  parent . auto parent_id = env.register_coop(std::move(parent)); //  . ... //      ,    . auto child = env.make_coop(parent_id); ... 

SObjectizer पर्यावरण के भीतर सहयोग के लिए भंडार का ढांचा भी नाटकीय रूप से बदल गया है। यदि संस्करण 5.5 समावेशी से पहले यह एक सामान्य शब्दकोश था, तो अब प्रत्येक सहयोग बाल सहकारिता के लिंक का भंडार है। यानी सहकारी संस्थाएं उपयोगकर्ता से छिपी एक विशेष जड़ सहकारी संस्था में एक जड़ के साथ एक पेड़ बनाती हैं।

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

 _test.bench.so_5.parallel_parent_child -r 4 -l 7 -s 5 Configuration: roots: 4, levels: 7, level-size: 5 parallel_parent_child: 15.69s 488280 488280 488280 488280 Total: 1953120 

यानी संस्करण 5.6.0 ~ 15.5 सेकंड में लगभग 2M सहयोग के साथ मुकाबला किया।

और यहाँ संस्करण 5.5.24.4 है, इस समय शाखा 5.5 का अंतिम भाग:

 _test.bench.so_5.parallel_parent_child -r 4 -l 7 -s 5 Configuration: roots: 4, levels: 7, level-size: 5 parallel_parent_child: 46.856s 488280 488280 488280 488280 Total: 1953120 

एक ही परिदृश्य, लेकिन परिणाम तीन गुना बदतर है।

केवल एक ही तरह के डिस्पैचर बचे हैं

डिस्पैचर SObjectizer के कोने में से एक हैं। यह डिस्पैचर्स हैं जो यह निर्धारित करते हैं कि एजेंट अपने संदेशों को कहाँ और कैसे संसाधित करेंगे। इसलिए, डिस्पैचर्स के विचार के बिना, शायद एक SObjectizer नहीं होता।

हालाँकि, डिस्पैचर्स स्वयं विकसित, विकसित और उस बिंदु पर विकसित हुए, जहाँ हमारे लिए SObjectizer-5.5 के लिए एक नया डिस्पैचर बनाना और भी मुश्किल नहीं था। लेकिन बहुत तकलीफदेह। हालाँकि, इसे क्रम में लेते हैं।

प्रारंभ में, सभी प्रेषणकर्ता जिन्हें आवश्यक आवेदन केवल SObjectizer के प्रारंभ में बनाया जा सकता है:

 so_5::launch( []( so_5::environment_t & env ) { /* -   */ }, //    SObjectizer-. []( so_5::environment_params_t & params ) { p.add_named_dispatcher("active_obj", so_5::disp::active_obj::create_disp()); p.add_named_dispatcher("shutdowner", so_5::disp::active_obj::create_disp()); p.add_named_dispatcher("groups", so_5::disp::active_group::create_disp()); ... } ); 

मैंने शुरुआत से पहले आवश्यक डिस्पैचर नहीं बनाया - सब कुछ, यह मेरी गलती है, आप कुछ भी नहीं बदल सकते।

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

 so_5::launch( []( so_5::environment_t & env ) { ... // - . //     . env.add_dispatcher_if_not_exists( "extra_dispatcher", []{ return so_5::disp::active_obj::create_disp(); } ); }, //    SObjectizer-. []( so_5::environment_params_t & params ) {...} ); 

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

 so_5::launch( []( so_5::environment_t & env ) { ... // - . //     . env.add_dispatcher_if_not_exists( "extra_dispatcher", []{ return so_5::disp::active_obj::create_disp(); } ); //         //    . auto coop = env.create_coop( "ping_pong", //     extra_dispatcher. so_5::disp::active_obj::create_disp_binder( "extra_dispatcher" ) ); coop->make_agent< a_pinger_t >(...); coop->make_agent< a_ponger_t >(...); ... }, //    SObjectizer-. []( so_5::environment_params_t & params ) {...} ); 

लेकिन सार्वजनिक डिस्पैचरों में एक अप्रिय विशेषता थी। जब वे SObjectizer पर्यावरण में जुड़ गए तो उन्होंने तुरंत काम करना शुरू कर दिया और जब तक SObjectizer पर्यावरण ने अपना काम पूरा नहीं किया तब तक काम करना जारी रखा।

फिर, समय के साथ, यह हस्तक्षेप करने लगा। यह सुनिश्चित करना आवश्यक था कि डिस्पैचरों को आवश्यकतानुसार जोड़ा जा सकता है और अनावश्यक भेजने वाले डिस्पैचर स्वचालित रूप से हटा दिए गए हैं।

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

सामान्य तौर पर, निजी डिस्पैचर्स डिस्पैचरों के विकास में एक बहुत ही सफल कड़ी बन गए, लेकिन उनके साथ काम करना सार्वजनिक डिस्पैचरों के साथ काम करने से बहुत अलग था:

 so_5::launch( []( so_5::environment_t & env ) { ... // - . //     . auto disp = so_5::disp::active_obj::create_private_disp(env); //         //    . auto coop = env.create_coop( "ping_pong", //      . disp->binder() ); coop->make_agent< a_pinger_t >(...); coop->make_agent< a_ponger_t >(...); ... }, //    SObjectizer-. []( so_5::environment_params_t & params ) {...} ); 

और भी अधिक निजी और सार्वजनिक डिस्पैचर कार्यान्वयन में भिन्न थे। इसलिए, कोड की नकल न करने और एक ही प्रकार के सार्वजनिक और अलग-अलग निजी डिस्पैचर को अलग से लिखने के लिए, मुझे टेम्पलेट और विरासत के साथ जटिल निर्माणों का उपयोग करना था।

नतीजतन, मैं यह सब विविधता के साथ थक गया था, और सोबिजाइज़र-5.6 में केवल एक प्रकार का डिस्पैचर बचा था। वास्तव में, यह निजी प्रेषणकर्ताओं का एक एनालॉग है। लेकिन केवल "निजी" शब्द के स्पष्ट उल्लेख के बिना। तो अब ऊपर दिखाए गए टुकड़े को इस प्रकार लिखा जाएगा:

 so_5::launch( []( so_5::environment_t & env ) { ... // - . //     . auto disp = so_5::disp::active_obj::make_dispatcher(env); //         //    . auto coop = env.create_coop( "ping_pong", //      . disp.binder() ); coop->make_agent< a_pinger_t >(...); coop->make_agent< a_ponger_t >(...); ... }, //    SObjectizer-. []( so_5::environment_params_t & params ) {...} ); 

केवल नि: शुल्क कार्य हैं, send_delayed और send_periodic शेष हैं

SObjectizer को संदेश भेजने के लिए API का विकास शायद सबसे महत्वपूर्ण उदाहरण है कि SObjectizer ने हमारे द्वारा उपलब्ध कंपाइलरों में C ++ 11 के समर्थन के रूप में कैसे बदलाव किया है।

सबसे पहले, संदेश इस तरह भेजे गए:

 mbox->deliver_message(new my_message(...)); 

या, यदि आप "सर्वश्रेष्ठ कुत्ता प्रजनकों की सिफारिशें" का पालन करते हैं (ग):

 std::unique_ptr<my_message> msg(new my_message(...)); mbox->deliver_message(std::move(msg)); 

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

 send<my_message>(target, ...); 

सच है, एक पूरे परिवार को एक साधारण send से send_to_agent कुछ समय लगा, जिसमें send_to_agent , send_delayed_to_agent , आदि शामिल हैं। और फिर, इस परिवार को send , send_delayed और send_periodic के परिचित सेट को संकीर्ण बनाने के send ।

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

लेकिन संस्करण 5.6.0 में, सार्वजनिक SObjectizer API में केवल मुफ्त send , send_delayed और send_periodic फ़ंक्शन सहेजे गए थे। बाकी सब कुछ या तो पूरी तरह से हटा दिया गया था या आंतरिक SObjectizer नामस्थानों में स्थानांतरित कर दिया गया था।

इसलिए SObjectizer-5.6 में, संदेश भेजने के लिए इंटरफ़ेस अंत में वही बन गया है जो अगर हम शुरू से ही सामान्य C ++ 11 समर्थन के साथ संकलक थे। ठीक है, इसके अलावा, अगर हमारे पास यह बहुत सामान्य सी ++ 11 का उपयोग करने का अनुभव था।

एकल प्रारूप send_delayed और send_periodic

send_delayed पिछले संस्करणों में send_delayed और send_periodic के साथ, एक और घटना थी।

टाइमर का उपयोग करने के लिए, आपके पास SObjectizer पर्यावरण का उपयोग होना चाहिए। एजेंट के अंदर SObjectizer पर्यावरण का एक लिंक होता है। और माचिन के अंदर भी ऐसी ही एक कड़ी है। लेकिन एमबॉक्स के अंदर वह नहीं थी। इसलिए, यदि एक लंबित संदेश एक एजेंट या माचिन को भेजा गया था, तो send_delayed कॉल send_delayed दिखता था:

 send_delayed<my_message>(target_agent, pause, ...); send_delayed<my_message>(target_mchain, pause, ...); 

Mbox के मामले के लिए, हमें कहीं और से SObjectizer पर्यावरण का लिंक लेना था:

 send_delayed<my_message>(this->so_environment(), target_mbox, pause, ...); 

send_delayed और send_periodic की यह विशेषता एक मामूली send_periodic थी। जो इतना हस्तक्षेप नहीं है, लेकिन बहुत कष्टप्रद है। और यह सब इसलिए कि शुरू में हमने SObjectizer Environment के लिंक को mbox-ahs में स्टोर करना शुरू नहीं किया था।

पिछले संस्करणों के साथ संगतता का उल्लंघन इस किरच से छुटकारा पाने का एक अच्छा कारण था।

अब आप mbox से यह पता कर सकते हैं कि यह किस SObjectizer पर्यावरण के लिए बनाया गया था। और इससे किसी भी प्रकार के टाइमर संदेश प्राप्तकर्ता के लिए एकल send_delayed और send_periodic का उपयोग करना संभव हो गया:

 send_delayed<my_message>(target_agent, pause, ...); send_delayed<my_message>(target_mchain, pause, ...); send_delayed<my_message>(target_mbox, pause, ...); 

शाब्दिक अर्थ में, "एक तिपहिया, लेकिन अच्छा है।"

कोई और अधिक तदर्थ एजेंट नहीं

जैसा कि कहा जाता है, "हर दुर्घटना का पहला नाम, मध्य नाम और अंतिम नाम होता है।" तदर्थ एजेंटों के मामले में, यह मेरा पहला नाम, मध्य नाम और अंतिम नाम है :(

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

वर्बोसिटी का एक स्रोत विशेष आधार प्रकार agent_t से विरासत में प्राप्त करने के लिए एजेंटों की आवश्यकता है। और इससे, ऐसा लगता है, कोई बच नहीं सकता है। या नहीं?

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

 auto pinger = coop->define_agent(); auto ponger = coop->define_agent(); pinger .on_start( [ponger]{ so_5::send< msg_ping >( ponger ); } ) .event< msg_pong >( pinger, [ponger]{ so_5::send< msg_ping >( ponger ); } ); ponger .event< msg_ping >( ponger, [pinger]{ so_5::send< msg_pong >( pinger ); } ); 

यानी उनकी अपनी कोई क्लास नहीं। हम सहयोग पर सिर्फ define_agent() कहते हैं और किसी प्रकार की एजेंट वस्तु प्राप्त करते हैं, जिसे आप आने वाले संदेशों के लिए सदस्यता ले सकते हैं।

इसलिए SObjectizer-5 में नियमित और तदर्थ एजेंटों में अलगाव था।

जो कोई भी दिखाई देने वाला बोनस नहीं लाया, इस तरह के अलगाव के लिए केवल अतिरिक्त श्रम लागत। और समय के साथ, यह स्पष्ट हो गया कि एड-हॉक एजेंट एक हैंडल के बिना एक सूटकेस की तरह हैं: इसे ले जाना मुश्किल है और इसे छोड़ने के लिए एक दया है। लेकिन SObjectizer-5.6 पर काम करते समय, इसे छोड़ने का फैसला किया गया था।

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

इसलिए, आपको जो कहा गया है उसमें बहुत सावधानी बरतनी चाहिए। और आप सुन सकते हैं (और फिर ध्यान से) केवल इस शिरा में यहाँ क्या कहा गया है: "मैंने आपके साधन पर ऐसा करने की कोशिश की और मुझे पसंद नहीं आया कि यहाँ कितना कोड मिला।" यहां तक ​​कि ऐसी इच्छाओं को बहुत सावधानी से व्यवहार किया जाना चाहिए: "मैं आपके विकास को ले जाऊंगा यदि यह यहां और यहां आसान होगा।"

दुर्भाग्य से, लगभग पांच साल पहले इंटरनेट पर "शुभचिंतकों" द्वारा "फ़िल्टरिंग" का कौशल अब की तुलना में बहुत कम था। इसलिए, SObjectizer में तदर्थ एजेंटों के रूप में ऐसा विशिष्ट प्रयोग।

SObjectizer-5.6 अब सिंक्रनाइज़ एजेंट इंटरैक्शन का समर्थन नहीं करता है

एजेंटों के बीच सिंक्रनाइज़ की गई बातचीत का विषय बहुत पुराना और पीड़ादायक है।

यह SObjectizer-4 के दिनों में शुरू हुआ। और SObjectizer-5 में जारी रहा। अब तक, अंत में, तथाकथित सेवा अनुरोध । जो शुरू में, बेशक, मौत के रूप में डरावना था। लेकिन फिर मैं उन्हें कम या ज्यादा सभ्य रूप देने में कामयाब रहा।

लेकिन यह एक ही मामला निकला जब पहला पैनकेक गुनगुना आया :(

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

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

सामान्य तौर पर, SObjectizer के रखरखाव / विकास के दौरान तुल्यकालिक अनुरोधों के साथ, बहुत अधिक सिरदर्द था। इतना अधिक कि पहले तो इन बहुत ही समकालिक अनुरोधों से छुटकारा पाने की ठोस इच्छा थी। और तब इस इच्छा का एहसास हुआ।

और इसलिए SObjectizer-5.6 में, एजेंट केवल अतुल्यकालिक संदेशों के माध्यम से फिर से बातचीत कर सकते हैं।

और चूंकि कई बार सिंक्रोनस इंटरेक्शन जैसी किसी चीज की जरूरत होती है, इसलिए इस तरह के इंटरेक्शन के लिए सपोर्टिंग के साथ सपोर्ट किया गया है।

 //    "-". using my_request_reply = so_5::extra::sync::request_reply_t<my_request, my_reply>; ... //  ,    . class request_handler final : public so_5::agent_t { ... //  .      . void on_request(typename my_request_reply::request_mhood_t cmd) { ... //  . //      cmd->request(). //   . cmd->make_reply(...); //      my_reply. } ... void so_define_agent() override { //       . so_subscribe_self().event(&request_handler::on_request); } }; ... //     . so_5::mbox_t handler_mbox = ...; //        15s. //    ,    . my_reply reply = my_request_reply::ask_value(handler_mbox, 15s, ...); //       my_request. 

यानी अब सिंक्रोनस अनुरोधों के साथ काम करना बुनियादी रूप से अलग है कि अनुरोध हैंडलर हैंडलर विधि से एक मान वापस नहीं करता है, जैसा कि पहले था। इसके बजाय, make_reply विधि का make_reply ।

नया कार्यान्वयन इस बात में अच्छा है कि अनुरोध और प्रतिक्रिया दोनों को नियमित अतुल्यकालिक संदेशों की तरह SObjectizer के अंदर भेजा जाता है। वास्तव में, make_reply send का थोड़ा अधिक विशिष्ट कार्यान्वयन है।

और, महत्वपूर्ण रूप से, नए कार्यान्वयन ने हमें कार्यक्षमता प्राप्त करने की अनुमति दी जो पहले अप्राप्य थी:

• सिंक्रोनस रिक्वेस्ट (यानी request_reply_t<Request, Reply> ऑब्जेक्ट्स) को अब सेव किया जा सकता है और / या दूसरे हैंडलर्स को फॉरवर्ड किया जा सकता है। विभिन्न भार संतुलन योजनाओं को लागू करना संभव बनाता है;
• आप अनुरोध की प्रतिक्रिया एजेंट के नियमित mbox में आने के लिए अनुरोध कर सकते हैं। और आरंभ करने वाला एजेंट किसी अन्य संदेश की तरह, प्रतिक्रिया को सामान्य तरीके से संसाधित करेगा;
• आप अलग-अलग प्राप्तकर्ताओं को एक ही बार में कई अनुरोध भेज सकते हैं, और फिर उन्हें प्राप्त होने वाले क्रम में प्रतिक्रियाओं को पार्स कर सकते हैं:

 using first_dialog = so_5::extra::sync::request_reply_t<first_request, first_reply>; using second_dialog = so_5::extra::sync::request_reply_t<second_request, second_reply>; //         . auto reply_ch = create_mchain(env); //     . first_dialog::initiate_with_custom_reply_to( one_service, reply_ch, so_5::extra::sync::do_not_close_reply_chain, ...); second_dialog::initiate_with_custom_reply_to( another_service, reply_ch, so_5::extra::sync::do_not_close_reply_chain, ...); //    . receive(from(reply_ch).handle_n(2).empty_timeout(15s), [](typename first_dialog::reply_mhood_t cmd) {...}, [](typename second_dialog::reply_mhood_t cmd) {...}); 

इसलिए, हम कह सकते हैं कि एसओबीजेनाइजर में सिंक्रोनस इंटरेक्शन के साथ निम्नलिखित हुआ:

• एक लंबे समय के लिए वह वैचारिक कारणों से चला गया था;
• तब इसे जोड़ा गया था और यह पता चला कि कई बार ऐसी बातचीत उपयोगी होती है;
• लेकिन अनुभव से पता चला है कि पहला कार्यान्वयन बहुत सफल नहीं है;
• पुराने कार्यान्वयन को पूरी तरह से फेंक दिया गया था, और बदले में एक नया कार्यान्वयन प्रस्तावित किया गया था।

उन्होंने अपनी गलतियों पर काम किया, सामान्य तौर पर।

निष्कर्ष

इस लेख ने, संक्षेप में, SObjectizer-5.6.0 में कई परिवर्तनों और इन परिवर्तनों के पीछे के कारणों के बारे में बात की।

परिवर्तनों की एक पूरी सूची यहां पाई जा सकती है ।

अंत में, मैं उन लोगों की पेशकश करना चाहूंगा जिन्होंने अभी तक सोबिजाइज़र की कोशिश नहीं की है, इसे ले लो और कोशिश करो। और हमारे साथ अपनी भावनाओं को साझा करें: आपको क्या पसंद आया, आपने क्या पसंद नहीं किया, क्या गायब था।

हम सभी रचनात्मक टिप्पणियों / सुझावों को ध्यान से सुनते हैं। इसके अलावा, हाल के वर्षों में, केवल किसी को एसओबीजेनाइज़र में शामिल करने की आवश्यकता है। इसलिए यदि आप हमें यह नहीं बताते हैं कि आप SObjectizer में क्या करना चाहते हैं, तो यह प्रकट नहीं होगा। और अगर तुम मुझे बताओ, तो कौन जानता है ...;)

परियोजना अब यहां रहती है और विकसित होती है । और जो लोग केवल GitHub का उपयोग करने के लिए उपयोग किए जाते हैं, उनके लिए GitHub दर्पण है । यह दर्पण पूरी तरह से नया है, इसलिए आप तारों की कमी को अनदेखा कर सकते हैं।

पुनश्च। आप इस Google समूह में SObjectizer संबंधित समाचारों का अनुसरण कर सकते हैं। वहां आप SObjectizer से संबंधित समस्याएं उठा सकते हैं।