Coroutines ने कभी नहीं छोड़ा, वे बस इस बीच अन्य चीजों से प्रभावित थे। एसिंक्रोनस प्रोग्रामिंग में हाल ही में बढ़ी हुई रुचि और इसलिए कॉरटाइन तीन कारकों के कारण काफी हद तक है: कार्यात्मक प्रोग्रामिंग तकनीकों की बढ़ती स्वीकृति, सच्चे समानता के लिए खराब समर्थन के साथ टूलसेट (जावास्क्रिप्ट! पायथन!), और सबसे महत्वपूर्ण बात: थ्रेड्स और कॉरटाइन के लिए अलग-अलग ट्रेडऑफ़। कुछ उपयोग मामलों के लिए, कोराउटीन उद्देश्यपूर्ण रूप से बेहतर हैं।
80, 90 और आज के सबसे बड़े प्रोग्रामिंग प्रतिमानों में से एक ओओपी है। यदि हम OOP के इतिहास को देखते हैं और विशेष रूप से सिमाला भाषा के विकास को देखते हैं, तो हम देखते हैं कि कक्षाएं कोरआउट से विकसित हुई हैं। असतत घटनाओं के साथ सिस्टम के अनुकरण के लिए सिमूला का इरादा था। सिस्टम का प्रत्येक तत्व एक अलग प्रक्रिया थी जो एक सिमुलेशन कदम की अवधि के लिए घटनाओं के जवाब में निष्पादित करेगा, फिर अन्य प्रक्रियाओं को अपना काम करने देने के लिए उपज। सिमाला 67 के विकास के दौरान वर्ग अवधारणा पेश की गई थी। अब कॉरटीन की लगातार स्थिति को ऑब्जेक्ट सदस्यों में संग्रहीत किया जाता है, और एक विधि को कॉल करके घटनाओं को चालू किया जाता है। अधिक जानकारी के लिए, पेपर को पढ़ने पर विचार करें । न्यागार्ड और डाहल द्वारा SIMULA भाषाओं का विकास ।
इसलिए एक मजेदार मोड़ में हम सभी के साथ कॉरआउट का उपयोग कर रहे हैं, हम बस उन्हें ऑब्जेक्ट्स और इवेंट-संचालित प्रोग्रामिंग कह रहे थे।
समानता के संबंध में, दो प्रकार की भाषाएं हैं: वे जो एक उचित मेमोरी मॉडल हैं, और जो नहीं हैं। एक स्मृति मॉडल "अगर मैं एक चर में लिखता हूं और उसके बाद दूसरे चर में उस चर से पढ़ता हूं, तो क्या मैं पुराने मूल्य या नए मूल्य या शायद एक अमान्य मूल्य देखता हूं? 'पहले' और 'बाद' का क्या अर्थ है? कौन से ऑपरेशन परमाणु होने की गारंटी है? ”
एक अच्छी मेमोरी मॉडल बनाना मुश्किल है, इसलिए यह प्रयास कभी भी इनमें से अधिकांश अनिर्दिष्ट, कार्यान्वयन-परिभाषित गतिशील ओपन-सोर्स भाषाओं के लिए नहीं किया गया है: पर्ल, जावास्क्रिप्ट, पायथन, रूबी, पीएचपी। बेशक, उन सभी भाषाओं को "स्क्रिप्टिंग" से परे विकसित किया गया था जो कि वे मूल रूप से बनाए गए थे। खैर, इनमें से कुछ भाषाओं में कुछ प्रकार के मेमोरी मॉडल दस्तावेज़ हैं, लेकिन वे पर्याप्त नहीं हैं। इसके बजाय, हमारे पास हैक हैं:
पर्ल को थ्रेडिंग समर्थन के साथ संकलित किया जा सकता है, लेकिन प्रत्येक थ्रेड में पूर्ण दुभाषिया राज्य का एक अलग क्लोन होता है, जिससे धागे निषेधात्मक रूप से महंगे हो जाते हैं। एकमात्र लाभ के रूप में, यह साझा-कुछ भी दृष्टिकोण डेटा दौड़ से बचा जाता है, और प्रोग्रामर को केवल कतारों / संकेतों / आईपीसी के माध्यम से संवाद करने के लिए मजबूर करता है। पर्ल के पास async प्रसंस्करण के लिए एक मजबूत कहानी नहीं है।
जावास्क्रिप्ट को हमेशा कार्यात्मक प्रोग्रामिंग के लिए समृद्ध समर्थन मिला है, इसलिए प्रोग्रामर मैन्युअल रूप से अपने कार्यक्रमों में निरंतरता / कॉलबैक को सांकेतिक शब्दों में बदलना होगा जहां उन्हें अतुल्यकालिक संचालन की आवश्यकता होती है। उदाहरण के लिए, अजाक्स अनुरोध या एनीमेशन देरी के साथ। चूंकि वेब स्वाभाविक रूप से async है, इसलिए बहुत से async जावास्क्रिप्ट कोड हैं और इन सभी कॉलबैक को प्रबंधित करना बेहद दर्दनाक है। इसलिए हम उन कॉलबैक को बेहतर तरीके से (प्रोमिस) व्यवस्थित करने या उन्हें पूरी तरह से खत्म करने के कई प्रयास देखते हैं।
पायथन में यह दुर्भाग्यपूर्ण विशेषता है जिसे ग्लोबल इंटरप्रेटर लॉक कहा जाता है। मूल रूप से पायथन मेमोरी मॉडल है "सभी प्रभाव क्रमिक रूप से दिखाई देते हैं क्योंकि कोई समानता नहीं है। एक समय में केवल एक धागा पायथन कोड चलाएगा। ”जबकि पायथन के पास थ्रेड्स हैं, लेकिन ये केवल टाउटाइन के रूप में शक्तिशाली हैं। [१] पाइथन जनरेटर के कार्यों के माध्यम से कई कोरटाइन को सांकेतिक शब्दों में बदलना कर सकता है yield। अगर सही तरीके से इस्तेमाल किया जाए, तो यह अकेले जावास्क्रिप्ट से जाने जाने वाले कॉलबैक नरक से बचा सकता है। पायथन 3.5 से अधिक हाल ही में async / प्रतीक्षा प्रणाली पायथन में अतुल्यकालिक मुहावरों को अधिक सुविधाजनक बनाती है, और एक घटना लूप को एकीकृत करती है।
[१]: तकनीकी रूप से ये प्रतिबंध केवल सीपीथॉन पर लागू होते हैं, पायथन संदर्भ कार्यान्वयन। Jython जैसे अन्य कार्यान्वयन वास्तविक धागे की पेशकश करते हैं जो समानांतर में निष्पादित कर सकते हैं, लेकिन समान व्यवहार को लागू करने के लिए महान लंबाई से गुजरना पड़ता है। अनिवार्य रूप से: प्रत्येक चर या वस्तु सदस्य एक अस्थिर चर है जिससे सभी परिवर्तन परमाणु होते हैं और तुरंत सभी थ्रेड्स में देखे जाते हैं। बेशक, अस्थिर चर का उपयोग करना सामान्य चर का उपयोग करने की तुलना में कहीं अधिक महंगा है।
मैं रूबी और PHP के बारे में पर्याप्त रूप से नहीं जानता कि उन्हें ठीक से भुना जाए।
संक्षेप में प्रस्तुत करने के लिए: इनमें से कुछ भाषाओं में मौलिक डिजाइन निर्णय हैं जो बहुउद्देशीय को अवांछनीय या असंभव बनाते हैं, जिससे कोरटाइन जैसे विकल्पों पर अधिक ध्यान केंद्रित होता है और एसिंक्स प्रोग्रामिंग को और अधिक सुविधाजनक बनाने के तरीकों पर।
अंत में, आइए कोरटाइन और थ्रेड्स के बीच अंतर के बारे में बात करते हैं:
थ्रेड्स मूल रूप से प्रक्रियाओं की तरह होते हैं, सिवाय इसके कि एक प्रक्रिया के अंदर कई थ्रेड्स एक मेमोरी स्पेस साझा करते हैं। इसका मतलब है कि थ्रेड्स स्मृति के संदर्भ में "हल्के वजन" से नहीं हैं। ऑपरेटिंग सिस्टम द्वारा थ्रेड्स पूर्व-निर्धारित हैं। इसका मतलब है कि कार्य स्विच में एक उच्च ओवरहेड है, और असुविधाजनक समय पर हो सकता है। इस ओवरहेड में दो घटक होते हैं: थ्रेड की स्थिति को निलंबित करने की लागत, और उपयोगकर्ता मोड (थ्रेड के लिए) और कर्नेल मोड (अनुसूचक के लिए) के बीच स्विच करने की लागत।
यदि कोई प्रक्रिया अपने स्वयं के थ्रेड को सीधे और सहकारी रूप से शेड्यूल करती है, तो कर्नेल मोड में संदर्भ स्विच अनावश्यक है, और स्विचिंग कार्य समान रूप से अप्रत्यक्ष फ़ंक्शन कॉल के लिए महंगा है, जैसे: काफी सस्ता। इन हल्के वजन के धागों को विभिन्न विवरणों के आधार पर हरे रंग के धागे, रेशे या कोरटाइन कहा जा सकता है। हरे रंग के धागे / तंतुओं के उल्लेखनीय उपयोगकर्ता प्रारंभिक जावा कार्यान्वयन थे, और हाल ही में गोलंग में गोरोटाइन्स। कोरआउटों का एक वैचारिक लाभ यह है कि उनके निष्पादन को नियंत्रण प्रवाह के संदर्भ में समझा जा सकता है जो स्पष्ट रूप से कोरटाइन के बीच आगे और पीछे से गुजरते हैं। हालाँकि, ये कोरआउट तब तक सही समानता नहीं प्राप्त करते हैं जब तक कि वे कई OS थ्रेड्स में शेड्यूल नहीं किए जाते हैं।
सस्ते कोराउटीन कहां उपयोगी हैं? अधिकांश सॉफ्टवेयर को एक गजियन थ्रेड्स की आवश्यकता नहीं होती है, इसलिए सामान्य महंगे धागे आमतौर पर ठीक होते हैं। हालाँकि, async प्रोग्रामिंग कभी-कभी आपके कोड को सरल बना सकती है। स्वतंत्र रूप से उपयोग किए जाने के लिए, इस अमूर्त को पर्याप्त रूप से सस्ता होना चाहिए।
और फिर वेब है। जैसा कि ऊपर उल्लेख किया गया है, वेब स्वाभाविक रूप से अतुल्यकालिक है। नेटवर्क अनुरोधों को बस एक लंबा समय लगता है। कई वेब सर्वर वर्कर थ्रेड से भरे थ्रेड पूल को बनाए रखते हैं। हालांकि, उनके अधिकांश समय ये धागे बेकार होंगे क्योंकि वे किसी संसाधन की प्रतीक्षा कर रहे हैं, क्या यह एक I / O घटना की प्रतीक्षा कर रहा है जब डिस्क से एक फ़ाइल लोड हो रही है, तब तक प्रतीक्षा करना जब तक कि ग्राहक ने प्रतिक्रिया का हिस्सा स्वीकार नहीं किया है, या एक डेटाबेस तक इंतजार कर रहा है। क्वेरी पूरी होती है। NodeJS ने असाधारण रूप से प्रदर्शित किया है कि एक परिणामी घटना-आधारित और अतुल्यकालिक सर्वर डिजाइन बहुत अच्छी तरह से काम करता है। जाहिर है कि जावास्क्रिप्ट वेब अनुप्रयोगों के लिए उपयोग की जाने वाली एकमात्र भाषा से दूर है, इसलिए अतुल्यकालिक वेब प्रोग्रामिंग को आसान बनाने के लिए अन्य भाषाओं (पायथन और सी # में ध्यान देने योग्य) के लिए एक बड़ा प्रोत्साहन भी है।