इवान तुलुप: हुड के तहत जेएस में अतुल्यकालिक

क्या आप इवान तुलुप को जानते हैं? सबसे अधिक संभावना है, आप अभी तक नहीं जानते हैं कि यह किस तरह का व्यक्ति है, और आपको उसकी हृदय प्रणाली की स्थिति का बहुत ध्यान रखने की आवश्यकता है।

इस बारे में और कैसे एसिंक्रोनसिज्म हुड के तहत जेएस में काम करता है, इवेंट लूप ब्राउज़र और Node.js में कैसे काम करता है, क्या कोई मतभेद हैं और शायद इसी तरह की बातें मिखाइल बशुरोव ( SaitoNakamura ) ने अपनी रिपोर्ट में RIT में बताई हैं ++। हम आपके साथ इस जानकारीपूर्ण प्रस्तुति की प्रतिलेख साझा करने की कृपा कर रहे हैं।



स्पीकर के बारे में: मिखाइल बशुरोव JSF और .NET लक्सॉफ्ट से फुलस्टैक वेब डेवलपर है। वह सुंदर यूआई, ग्रीन परीक्षण, वाष्पीकरण, संकलन, संकलक तकनीक की अनुमति देता है और देव अनुभव में सुधार करता है।

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

दादा इवान तुलुप

इवान तुलुप के लिए मेरी उम्मीदवारी थी।



लेकिन मैंने तय किया कि मैं एक और कन्फर्मिस्ट पथ पर जाऊँगा, इसलिए मिलेंगे - दादा इवान तुलुप!



वास्तव में, केवल दो चीजों के बारे में उसके बारे में पता होना चाहिए:

1. उसे ताश खेलना पसंद है।
2. वह, सभी लोगों की तरह, एक दिल है, और यह धड़कता है।

हार्ट अटैक के तथ्य

आपने सुना होगा कि हृदय रोग और उनसे मृत्यु दर के मामले हाल ही में अधिक बार हुए हैं। संभवत: सबसे आम दिल की बीमारी दिल का दौरा है, यानी दिल का दौरा।

हार्ट अटैक के बारे में क्या दिलचस्प है?

• सबसे अधिक बार, यह सोमवार सुबह होता है।
• एकल लोगों में, दिल का दौरा पड़ने का जोखिम दो गुना अधिक होता है। यहां, शायद, बिंदु पूरी तरह से सहसंबंध में है, और एक कारण संबंध में नहीं। दुर्भाग्य से (या सौभाग्य से), हालांकि, ऐसा है।
• ऑपरेशन के दौरान दिल का दौरा पड़ने से दस कंडक्टरों की मौत हो गई (जाहिरा तौर पर बहुत घबराए हुए काम!)।
• दिल का दौरा दिल की मांसपेशियों का एक परिगलन है जो रक्त प्रवाह की कमी के कारण होता है।

हमारे पास एक कोरोनरी धमनी है जो रक्त को मांसपेशियों (मायोकार्डियम) में लाती है। यदि रक्त इसे खराब रूप से प्रवाह करना शुरू कर देता है, तो मांसपेशी धीरे-धीरे मर जाती है। स्वाभाविक रूप से, यह हृदय और उसके काम पर एक अत्यंत नकारात्मक प्रभाव डालता है।

दादाजी इवान तुलुप का दिल भी है, और यह धड़कता है। लेकिन हमारा दिल रक्त पंप करता है, और इवान तुलुप का दिल हमारे कोड और हमारे दुखों को पंप करता है।

कार्य: रक्त परिसंचरण का एक बड़ा चक्र

कार्य क्या हैं? आमतौर पर एक ब्राउज़र में आलसी क्या हो सकता है? उनकी आखिर जरूरत क्यों है?

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



गोभी के कई अलग-अलग स्रोत हैं, विनिर्देश के अनुसार उनमें से बहुत सारे हैं। हमारा दिल धड़कता रहता है, और जब यह धड़कता है, तो हमारे साथ सब कुछ ठीक है।

ब्राउज़र में इवेंट लूप: सरलीकृत संस्करण

यह एक बहुत ही सरल चित्र में दर्शाया जा सकता है।

• एक कार्य है, हमने इसे पूरा कर लिया है।
• फिर हम ब्राउज़र रेंडर को निष्पादित करते हैं।

लेकिन वास्तव में, यह आवश्यक नहीं है, क्योंकि कुछ मामलों में ब्राउज़र दो कार्यों के बीच रेंडर नहीं कर सकता है।

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

इसलिए, रेंडर वास्तव में प्रत्येक कार्य के बाद नहीं किया जाता है।

कार्य: वर्गीकरण

संभावित संचालन दो प्रकार के होते हैं:

1. I / O बाध्य;
2. सीपीयू बाउंड।

सीपीयू बाउंड हमारा उपयोगी काम है जो हम करते हैं (विश्वास, प्रदर्शन, आदि)

I / O बाध्य वे बिंदु हैं जिन पर हम अपने कार्यों को साझा कर सकते हैं। यह हो सकता है:

• समय समाप्त।

हमने 5000 एमबी का सेटटाइमआउट किया, और हम इन 5000 एमएस का इंतजार करते हैं, लेकिन हम अन्य उपयोगी काम कर सकते हैं। केवल जब यह समय बीतता है, हम कॉलबैक प्राप्त करते हैं, और इसमें कुछ काम करते हैं।

• xhr / fetch।

हम ऑनलाइन गए। जबकि हम नेटवर्क से प्रतिक्रिया की प्रतीक्षा कर रहे हैं, हम अभी इंतजार कर रहे हैं, लेकिन हम कुछ उपयोगी भी कर सकते हैं।

• नेटवर्क (OBD)।

या, उदाहरण के लिए, हम नेटवर्क बीडी पर जाते हैं। हम Node.js के बारे में भी बात कर रहे हैं, जिसमें शामिल हैं, और अगर हम Node.js कृपया नेटवर्क से कहीं जाना चाहते हैं - यह एक ही संभावित I / O बाध्य कार्य (इनपुट / आउटपुट) है।

• फ़ाइल।

फ़ाइल पढ़ें - संभवतः यह सीपीयू बाउंड कार्य नहीं है। Node.js में, यह थोड़े टेढ़े लिनक्स API के कारण थ्रेड पूल में चलता है, ईमानदार होने के लिए।

तब सीपीयू इनबाउंड है:

• उदाहरण के लिए, जब हम / के लिए / (?) लूप के लिए करते हैं या हम किसी भी तरह से अतिरिक्त तरीकों का उपयोग करके सरणी से गुजरते हैं: फ़िल्टर, मानचित्र, आदि।
• JSON.parse या JSON.stringify, अर्थात् संदेश क्रमांकन / डीरिएलाइज़ेशन। यह सब सीपीयू पर किया जाता है, हम सिर्फ इसके लिए इंतजार नहीं कर सकते कि यह कहीं जादुई तरीके से किया गया है।
• काउंटिंग हैश, यानी, क्रिप्टो माइनिंग।

बेशक, क्रिप्टो को GPU पर भी खनन किया जा सकता है, लेकिन मुझे लगता है - GPU, CPU - आप इस सादृश्य को समझते हैं।

कार्य: अतालता और थ्रोम्बस

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

मुझे लगता है कि हर कोई समझता है कि अतालता एक अप्रिय हृदय रोग है। लेकिन आप अभी भी उसके साथ रह सकते हैं। यदि आप एक ऐसा कार्य करते हैं, जो पूरे इवेंट लूप को एक अंतहीन लूप में लटका देता है? आप कोरोनरी या किसी अन्य धमनी में रक्त का थक्का डालते हैं, और सब कुछ पूरी तरह से उदास हो जाएगा। दुर्भाग्य से, हमारे दादा इवान तुलुप मर जाएंगे।

तो दादा इवान मर गया ...

हमारे लिए, इसका मतलब है कि संपूर्ण टैब पूरी तरह से जम जाता है - आप किसी भी चीज़ पर क्लिक नहीं कर सकते, और फिर क्रोम कहता है: "अरे, स्नैप!"

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

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

फिलिप रॉबर्ट्स डेमो: फिलिप रॉबर्ट्स द्वारा लूप

एक उदाहरण पर विचार करें:

$.on('button', 'click', function onClick(){ console.log('click'); }); setTimeout(function timeout() { console log("timeout"); }. 5000); console.log(“Hello world"); 

सार यह है: हमारे पास एक बटन है, हम इसकी सदस्यता लेते हैं (addEventListener), Timeout को 5 सेकंड के लिए कॉल किया जाता है और तुरंत कंसोल में भेज दिया जाता है। हम "Hello, world!" लिखते हैं, setTimeout में हम Timeout लिखते हैं, जिस पर हम लिखते हैं क्लिक करें।

यदि हम इसे चलाते हैं और कई बार हम बटन पर क्लिक करते हैं तो क्या होगा - टाइमआउट वास्तव में कब निष्पादित किया जाएगा? आइए देखें डेमो:


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

यहाँ, onClick तेज़ है, लेकिन यदि आप एक लंबा कार्य करते हैं, तो सब कुछ स्थिर हो जाएगा, जैसा कि पहले ही समझाया गया है। यह बहुत ही सरल उदाहरण है। यहां एक बारी है, लेकिन ब्राउज़रों में, वास्तव में, सब कुछ ऐसा नहीं है।

घटनाओं को किस क्रम में निष्पादित किया जाता है - HTML विनिर्देशन क्या कहता है?

वह निम्नलिखित कहती है: हमारे पास 2 अवधारणाएँ हैं:

1. कार्य स्रोत;
2. कार्य कतार।

टास्क सोर्स एक तरह का टास्क है। यह उपयोगकर्ता इंटरैक्शन हो सकता है, वह है, onClick, onChange - कुछ ऐसा जो उपयोगकर्ता के साथ इंटरैक्ट करता है; या टाइमर, अर्थात् सेटटाइमआउट और सेटइंटरवल, या पोस्टमेसेज; या यहां तक ​​कि पूरी तरह से जंगली प्रकार जैसे कैनवस ब्लॉब सीरियलाइज़ेशन कार्य स्रोत - एक अलग प्रकार भी।

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

ब्राउज़र प्राथमिकताएँ और कार्य कतार

कल्पना कीजिए कि हमारे पास 3 लाइनें हैं:

1. उपयोगकर्ता बातचीत;
2. समय समाप्ति;
3. संदेश पोस्ट करें।

ब्राउज़र को इन कतारों से कार्य मिलने लगते हैं:

• सबसे पहले, वह ऑनफोकस यूजर इंटरैक्शन लेता है - यह बहुत महत्वपूर्ण है - एक दिल की धड़कन चली गई है।
  
• फिर वह पोस्टमैसेज लेता है - ठीक है, पोस्टमासेजेज बहुत उच्च प्राथमिकता है, शांत!
  
• अगले एक, onChange, प्राथमिकता में उपयोगकर्ता इंटरैक्शन से फिर से है।
  
• अगलाक्लिक पर भेजा जाता है। उपयोगकर्ता सहभागिता कतार समाप्त हो गई है, हमने उपयोगकर्ता को वह सब कुछ प्रदर्शित किया है जिसकी आवश्यकता है।
  
• फिर हम सेट इन्टरवल लेते हैं, पोस्टमेसेज जोड़ते हैं।
  
• setTimeout केवल सबसे हाल ही में निष्पादित करेगा । वह लाइन के अंत में कहीं था।
  

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

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

खैर, इन कार्यों को किया जाता है। किस बिंदु पर हम अपना कार्य समाप्त करते हैं और समझते हैं कि हम अगला ले सकते हैं, या जिसे हम प्रस्तुत कर सकते हैं?

अनेकता

स्टैक एक सरल डेटा संरचना है जो "पिछले में - पहले बाहर" के सिद्धांत पर काम करती है, अर्थात। "मैंने आखिरी डाल दिया - आप पहले वाले को प्राप्त करें । " निकटतम, संभवतः असली समकक्ष कार्ड का एक डेक है। इसलिए, हमारे दादा इवान तुलुप को ताश खेलना पसंद है।



उपरोक्त उदाहरण, जिसमें कुछ कोड है, उसी उदाहरण को प्रस्तुति में पोक किया जा सकता है। कुछ जगह पर हम हैंडल क्लिक करते हैं, कंसोल.लॉग दर्ज करते हैं, शोपॉप और विंडो कहते हैं। पुष्टि। चलो एक स्टैक बनाते हैं।

• तो, पहले हम हैंडल लेते हैं और कॉल को स्टैक पर इस फंक्शन पर धकेल देते हैं - बढ़िया!
• फिर हम उसके शरीर में जाते हैं और उसे अंजाम देते हैं।
• हम स्टैक पर कंसोल डालते हैं और तुरंत इसे निष्पादित करते हैं, क्योंकि इसे निष्पादित करने के लिए सब कुछ है।
• इसके बाद हमने शो कॉनफर्म लगाया - यह एक फंक्शन कॉल है - शानदार।
• हम स्टैक पर फ़ंक्शन डालते हैं - हम इसके शरीर को डालते हैं, अर्थात्, विंडो। कॉन्फर्म।

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

एक सरणी को विखंडू में विभाजित करना और उन्हें अतुल्यकालिक रूप से संसाधित करना

आइए सबसे "माथे" उदाहरण देखें। मैं आपको तुरंत चेतावनी देता हूं: कृपया इसे घर पर दोहराने की कोशिश न करें - यह संकलन नहीं करेगा।



हमारे पास एक बड़ा, बड़ा सरणी है, और हम इसके आधार पर कुछ गणना करना चाहते हैं, उदाहरण के लिए, कुछ बाइनरी डेटा को पार्स करने के लिए। हम बस इसे विखंडू में तोड़ सकते हैं: इस टुकड़े को संसाधित करें, यह और यह। हम चंक के आकार का चयन करते हैं, उदाहरण के लिए, 10 हजार तत्व, हम विचार करते हैं कि हमारे पास कितने टुकड़े होंगे। हमारे पास एक parseData फ़ंक्शन है जो सीपीयू बाउंड में जाता है और वास्तव में कुछ भारी कर सकता है। फिर हम सरणी को विखंडू में तोड़ते हैं, सेटटाइमआउट करते हैं () => पार्सेडाटा (टुकड़ा), 0)।

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

लेकिन यह वास्तव में एक बहुत ही "माथे" उदाहरण है। ब्राउज़रों में कई एपीआई हैं जो आपको अधिक विशिष्ट तरीके से ऐसा करने में मदद करते हैं।

सेटटाइमआउट और सेटइंटरवल के अलावा, एपीआई हैं जो सीमाओं से परे हैं, जैसे कि, उदाहरण के लिए, requestAnimationFrame और requestIdleCallback।

शायद बहुत से requestAnimationFrame से परिचित हैं, और यहां तक ​​कि पहले से ही इसका उपयोग करते हैं। यह प्रतिपादन से पहले निष्पादित किया जाता है। इसका आकर्षण यह है कि, सबसे पहले, यह हर 60 एफपीएस (या 30 एफपीएस) को निष्पादित करने की कोशिश करता है, और दूसरी बात, यह सब सीएसएस ऑब्जेक्ट मॉडल, आदि बनाने से तुरंत पहले किया जाता है।



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

इसके अलावा इसमें requestIdleCallback भी है । हो सकता है कि आपने सुना हो कि इसका उपयोग रिएक्ट v16.0 (फाइबर) में किया जाता है। RequestIdleCallback इस तरह से काम करती है कि यदि ब्राउज़र समझता है कि उसके पास कुछ उपयोगी करने के लिए फ्रेम (60 एफपीएस) के बीच का समय है, और साथ ही उन्होंने पहले से ही सब कुछ कर लिया है - उन्होंने कार्य किया, अनुरोध किया गया। छोटे क्वांटा का उत्पादन कर सकते हैं, कहते हैं, प्रत्येक 50 एमएस, तो आप कुछ कर सकते हैं (आईडीएल मोड)।

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

यह आपके लिए गारंटी है कि यदि आपके पास ऐसा काम है जो DOM को बदलने से संबंधित नहीं है (क्योंकि तब requestAnimationFrame एनीमेशन और इसी तरह से है), जबकि यह सुपर प्राथमिकता नहीं है, लेकिन मूर्त है, तो requestIdleCallback आपका काम है।

इसलिए, यदि हमारे पास एक लंबा सीपीयू बाउंड ऑपरेशन है, तो हम इसे टुकड़ों में तोड़ने की कोशिश कर सकते हैं।

• यदि यह एक DOM परिवर्तन है, तो requestAnimationFrame का उपयोग करें।
  
• यदि यह एक गैर-प्राथमिकता, अल्पकालिक और मुश्किल काम है जो सीपीयू को अधिभार नहीं देगा, तो requestIdleCallback।
  
• यदि हमारे पास एक बड़ा शक्तिशाली कार्य है जिसे लगातार करने की आवश्यकता है, तो हम ईवेंट लूप से परे जाते हैं और वेबवर्क का उपयोग करते हैं। और कोई उपाय नहीं है।
  

ब्राउज़र में कार्य:

1. छोटे-छोटे कार्यों में सब कुछ कुचल दें।
2. कई प्रकार के कार्य हैं।
3. विनिर्देश कतारों के माध्यम से कार्य इन प्रकारों द्वारा प्राथमिकता दी जाती है।
4. बहुत कुछ ब्राउज़र द्वारा तय किया जाता है, और यह समझने का एकमात्र तरीका है कि यह कैसे काम करता है बस यह जांचना है कि एक या कोई अन्य कोड चल रहा है या नहीं।
5. लेकिन विनिर्देश हमेशा सम्मानित नहीं होता है!

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

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

टर्मिनेटर सांता: मेस्कॉट लूप नोड.जेएस पर

Node.js किसी को अधिक पसंद है।



क्योंकि एक तरफ यह दाढ़ी के साथ एक ही दादा है, लेकिन एक ही समय में सब कुछ चरणों में वितरित किया जाता है और यह स्पष्ट रूप से चित्रित किया जाता है कि क्या किया जाता है।

Node.js में इवेंट लूप के चरण:

• टाइमर;
  
• लंबित कॉलबैक;
  
• बेकार, तैयार करना;
  
• पोल;
  
• जांच;
  
• करीबी कॉलबैक।
  

अंतिम को छोड़कर सब कुछ बहुत स्पष्ट नहीं है कि इसका क्या मतलब है। चरणों में ऐसे अजीब नाम हैं, क्योंकि हुड के नीचे, जैसा कि हम पहले से ही जानते हैं, हमारे पास सभी को शासन करने के लिए लिबुव है:

• लिनक्स - epoll / POSIX AIO;
  
• बीएसडी - केकेयू;
  
• विंडोज - IOCP;
  
• सोलारिस - घटना बंदरगाहों।
  

उन सभी के हजारों!

इसके अलावा, Libuv भी एक ही इवेंट लूप प्रदान करता है। इसमें Node.js की बारीकियां नहीं हैं, लेकिन चरण हैं, और Node.js सिर्फ उनका उपयोग करते हैं। लेकिन किसी कारणवश उसने वहां से नाम ले लिया।

आइए देखें कि प्रत्येक चरण का वास्तव में क्या मतलब है।

टाइमर चरण प्रदर्शन करता है:

• कॉलबैक तैयार टाइमर;
  
• setTimeout और setInterval;
  
• लेकिन नहीं सेटइमाउडेट एक अलग चरण है।
  

चरण लंबित कॉलबैक

इससे पहले, प्रलेखन चरण I / O कॉलबैक कहलाता है। हाल ही में, इस दस्तावेज़ को सही कर दिया गया था, और यह स्वयं विरोधाभासी हो गया। इससे पहले, एक स्थान पर यह लिखा गया था कि I / O कॉलबैक इस चरण में निष्पादित किए जाते हैं, दूसरे में - कि चुनाव चरण में। लेकिन अब सब कुछ वहाँ लिखा गया है असमान और अच्छी तरह से, इसलिए प्रलेखन पढ़ें - कुछ और अधिक समझ में आ जाएगा।

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

फेस आइडल, तैयार

इस चरण में, हम कुछ भी नहीं कर सकते हैं, इसलिए हम इसे सिद्धांत रूप में भूल जाएंगे।

पोल चरण

यह Node.js में सबसे दिलचस्प चरण है क्योंकि यह मुख्य उपयोगी कार्य करता है:

• I / O कॉलबैक करता है (कॉलबैक चरण लंबित नहीं है!)।
• I / O से घटनाओं की प्रतीक्षा कर रहा है;
• यह सेटिमिटेड करने के लिए अच्छा है;
• कोई समय नहीं;

आगे देखते हुए, setImmediate अगले चेक चरण में निष्पादित होगा, अर्थात, टाइमर से पहले की गारंटी।

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

एक गैर-अवरोधक मॉडल कैसे लागू किया जाता है? उदाहरण के लिए, एक ही एपोल में, हम एक घटना की सदस्यता ले सकते हैं - एक सॉकेट खोलें और उस पर कुछ लिखे जाने की प्रतीक्षा करें। इसके अलावा, दूसरा तर्क टाइमआउट है, अर्थात हम एपोल का इंतजार करेंगे, लेकिन यदि समय समाप्त हो जाता है, और आई / ओ से घटना नहीं आती है, तो यह समय समाप्त हो जाएगा। यदि नेटवर्क से कोई घटना हमारे पास आती है (कोई सॉकेट को लिखता है), तो यह आएगा।

इसलिए, चरण चरण हीप से सबसे शुरुआती कॉलबैक को पुनर्प्राप्त करता है (हीप एक डेटा संरचना है जो अच्छी तरह से सॉर्ट किए गए वितरण और वितरण की अनुमति देता है), इसका टाइमआउट लेता है, इस टाइमआउट को लिखता है और सब कुछ जारी करता है। इस प्रकार, भले ही सॉकेट में कोई भी हमें नहीं लिखता है, टाइमआउट काम करेगा, चुनाव के चरण में वापस आ जाएगा और काम जारी रहेगा।

यह ध्यान रखना महत्वपूर्ण है कि मतदान के चरण में एक बार में कॉलबैक की संख्या की सीमा होती है।

यह दुखद है कि शेष चरणों में यह नहीं है। यदि आप 10 बिलियन टाइमआउट जोड़ते हैं, तो आप 10 बिलियन टाइमआउट जोड़ते हैं। इसलिए, अगला चरण चेक चरण है।

जाँच चरण

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

चरण बंद कॉलबैक

यह चरण हमारे सभी सॉकेट क्लोजर कॉलबैक और अन्य प्रकारों को निष्पादित नहीं करता है:

 socket.on('close', …). 

वह केवल उन्हें निष्पादित करती है यदि यह घटना अप्रत्याशित रूप से उड़ती है, उदाहरण के लिए, किसी दूसरे छोर पर भेजा गया: "सब कुछ - सॉकेट बंद करें - यहां से जाएं, वास्या!" फिर यह चरण काम करेगा, क्योंकि घटना अप्रत्याशित है। लेकिन यह हमें विशेष रूप से प्रभावित नहीं करता है।

Node.js में विखंडू के गलत अतुल्यकालिक प्रसंस्करण

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

 const bigArray = [1..1_000_000] const chunks = getChunks(bigArray) const parseData = (slice) => // parse binary data for (chunk of chunks) { setTimeout(() => parseData(slice), 0) } 

क्या आपको लगता है कि इससे कोई समस्या है?

मैं पहले से ही थोड़ा आगे चला गया जब मैंने कहा कि यदि आप 10 हजार टाइमआउट (या 10 बिलियन!) जोड़ते हैं, तो कतार में 10 हजार टाइमर होंगे, और वह मिल जाएगा और उन्हें निष्पादित करेगा - इससे कोई सुरक्षा नहीं है: प्राप्त करें - निष्पादित करें, प्राप्त करें - पूरा करने के लिए और इतने पर विज्ञापन infinitum।

केवल पोल चरण, अगर हमें लगातार I / O से कोई घटना मिलती है, तो हर समय कोई व्यक्ति सॉकेट में कुछ लिखता है ताकि हम कम से कम टाइमर और सेटइमाइड निष्पादित कर सकें, इसकी सीमा सुरक्षा है, और यह सिस्टम-निर्भर है। यही है, यह अलग-अलग ऑपरेटिंग सिस्टम पर अलग होगा।

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

लेकिन क्या आपको लगता है कि अगर हम setTimeout ((= = parseData (slice), 0) को setImmediate (() => parseData (slice)) से बदल दें तो कुछ बदल जाएगा? - स्वाभाविक रूप से, नहीं, वहां चेक चरण पर भी कोई सुरक्षा नहीं है।

इस समस्या को हल करने के लिए, आप पुनरावर्ती प्रसंस्करण को कॉल कर सकते हैं।

 const parseData = (slice) => // parse binary data const recursiveAsyncParseData = (i) => { parseData(getChunk(i)) setImmediate(() => recursiveAsyncParseData(i + 1)) } recursiveAsyncParseData(0) 

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

सच है, समस्या यह है कि यह अभी भी किसी प्रकार का सीपीयू बाध्य कार्य है। शायद वह अभी भी किसी तरह से वजन और इवेंट लूप में समय लेगी। सबसे अधिक संभावना है कि आप चाहते हैं कि आपका Node.js विशुद्ध रूप से I / O बाध्य हो।
इसलिए, कुछ अन्य चीजों का उपयोग करना बेहतर है, उदाहरण के लिए, प्रक्रिया कांटा / धागा पूल।

अब हम Node.js के बारे में जानते हैं कि:

• सब कुछ चरणों में वितरित किया जाता है - ठीक है, हम स्पष्ट रूप से यह जानते हैं;
  
• बहुत लंबे मतदान चरण के खिलाफ सुरक्षा है, लेकिन बाकी नहीं;
  
• घटना लूप को अवरुद्ध नहीं करने के लिए पुनरावर्ती प्रसंस्करण पैटर्न लागू किया जा सकता है;
• लेकिन प्रक्रिया कांटा, धागा पूल, बाल प्रक्रिया का उपयोग करना बेहतर है

आपको थ्रेड पूल से भी सावधान रहना चाहिए, क्योंकि Node.js वहां से चीजें शुरू करता है, विशेष रूप से, DNS रिज़ॉल्यूशन, क्योंकि लिनक्स के लिए, किसी कारण से, DNS समाधान फ़ंक्शन अतुल्यकालिक नहीं है। इसलिए, इसे थ्रेडपूल में निष्पादित किया जाना चाहिए। विंडोज पर, सौभाग्य से, ऐसा नहीं है। लेकिन वहां आप फाइल को एसिंक्रोनस रूप से पढ़ सकते हैं। लिनक्स में, दुर्भाग्य से, यह असंभव है।

मेरी राय में, थ्रेडपूल में मानक सीमा 4 प्रक्रियाएं हैं। इसलिए, यदि आप सक्रिय रूप से वहां कुछ करते हैं, तो यह हर किसी के साथ प्रतिस्पर्धा करेगा - एफएस और अन्य के साथ। आप थ्रेडपूल बढ़ाने पर विचार कर सकते हैं, लेकिन बहुत सावधानी से भी। इसलिए इस विषय पर कुछ पढ़ें।

माइक्रोटॉक: फुफ्फुसीय परिसंचरण

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

ब्राउज़रों में माइक्रोटॉक

यह समझने के लिए कि माइक्रोटस्क कैसे काम करता है, हम व्हाट्सएप मानक के अनुसार घटना लूप एल्गोरिदम की ओर मुड़ते हैं, अर्थात, विनिर्देश पर जाएं और देखें कि यह सब कैसे दिखता है।



मानव भाषा में अनुवाद, यह कुछ इस तरह दिखता है:

• हमारी लाइन से मुक्त कार्य ले लो
• हम इसे बाहर ले जाते हैं
• हम माइक्रोटस्क चेकपॉइंट करते हैं - ठीक है, हम अभी भी नहीं जानते कि यह क्या है, लेकिन हम इसे याद करते हैं।
• हम रेंडरिंग को अपडेट करते हैं (यदि आवश्यक हो), और एक वर्ग में लौटें।

वे आरेख पर इंगित किए गए स्थान में और कई और स्थानों पर किए जाते हैं, जिनके बारे में हम जल्द ही जानेंगे। यही है, कार्य समाप्त हो गया है, माइक्रोटस्क निष्पादित किए जाते हैं।

माइक्रोटैक्स के स्रोत

• Promise.then।

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

• उत्परिवर्ती पर्यवेक्षक।
  
• ऑब्जेक्ट.बॉब , जो कि डिप्रेस्ड हो और किसी की जरूरत न हो।
  

Mutation observer का उपयोग कितने करते हैं?

मुझे लगता है कि कुछ म्यूटेशन ऑब्जर्वर का उपयोग करते हैं। सबसे अधिक संभावना है, Promise.then का उपयोग अधिक किया जाता है, इसलिए हम इसे उदाहरण में विचार करेंगे।

माइक्रोटस्क चेकपॉइंट की विशेषताएं:

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

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


हमारे पास दो दिल हैं। मैं जेएस एनीमेशन के साथ पहले दिल को एनिमेटेड करता हूं, और सीएसएस एनीमेशन के साथ दूसरा। एक और बड़ी विशेषता है जिसे स्टार्वमाइक्रोटॉक्स कहा जाता है। हम Promise.resolve को कॉल करते हैं, और फिर उसी फ़ंक्शन को तब डालते हैं।
प्रस्तुति में देखें कि क्या होता है यदि आप इस फ़ंक्शन को कहते हैं।

हां, जेएस का दिल बंद हो जाएगा, क्योंकि हम एक माइक्रोटस्क जोड़ते हैं, और फिर हम इसमें एक माइक्रोटस्क जोड़ते हैं, और फिर हम इसमें एक माइक्रोटस्क जोड़ते हैं ... और इसलिए अंतहीन।

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

इसके अलावा, जैसा कि हम याद करते हैं, स्टैक क्लीनअप के अंत में माइक्रोटस्क निष्पादित किया जाता है। हमें याद है कि स्टैक क्या है। यह पता चला है कि जैसे ही हम अपने कोड से बाहर निकले, सेटटाइमआउट कॉलबैक को निष्पादित किया गया - यही वह है - माइक्रोटेस्क वहीं। इससे दिलचस्प दुष्प्रभाव हो सकते हैं।

एक उदाहरण पर विचार करें।



एक बटन और एक ग्रे कंटेनर है जिसमें यह निहित है। हम बटन और कंटेनर दोनों के क्लिक की सदस्यता लेते हैं। , , , .

2 :

1. Promise.resolve;
2. .then, console.log('RO')

«FUS», – «DAH!» ( ).

, ? , , «FUS RO DAH!» बहुत बढ़िया! , .



, , . – . , - ?



! .



, .

, , , . , .

• — buttonHandleClick, .
• Promise.resolve. . , console.log('RO') . .
• console.log('FUS').
• buttonHandleClick . .
• , (divHandleClick) , «DAH!».
• HandleClick .

, . ? :

• button.click(). .
• button HandleClick.
• Promise.resolve then. , Promise.resolve .
• console.log «FUS».
• buttonHandleClick , .

(click) , , . divHandleClick , , console.log('DAH!') . , .

, , button.click .
. , , . , , .

: () ( ). - , , stopPropagation. , , , , - , .

, - ( junior-) — «», promise, , then , - . , , : , , . . , - .

( 4) , . , , , , - . .

, :

• Event Loop. यह अप्रिय है।
• , .

, . — , , .

Node.js

Node.js Promise.then process.nextTick. , — . , , , , .

process.nextTick

, process.nextTick, setImmediate? Node.js ?

. createServer, EventEmitter, , listen ( ), .

 const createServer = () => { const evEmitter = new EventEmitter() return { listen: port => { evEmitter.emit('listening', port) return evEmitter } } } const server = createServer().listen(8080) server.on('listening', () => console.log('listening')) 

, , 8080, listening console.log - .

, , - .

createServer, . listen, , . .

, , . ? process.nextTick: evEmitter.emit('listening', port) process.nextTick(() => evEmitter.emit('listening', port)).

, process.nextTick , . EventEmitter, . , , API, . process.nextTick, emit , userland . createServer, , listen, listening. — process.nextTick — ! , , .

process.nextTick . , .

, process.nextTick , Promise.then . process.nextTick , — , Event Loop, Node.js. , , .

process.nextTick , ghbvtybnm setImmediate , C++ .. process.nextTick .

Async/await

API — async/await, - . . , async/await Promise, Event Loop . , .

• .
  
• Philip Roberts. What the heck is the event loop anyway?
  
• Bert Belder. Everything you need to know about Node.js event loop.
  
• Jake Archibald. In the Loop .
  
• The Node.js Event Loop, Timers, and process.nextTick()
  
• WHATWG Specification event loop processing model
  

, !

Frontend Conf — 4 5 , . , :

• Grid Layout / ( .)
  
• Building decentralised apps with JS / (ING)
  
• / ()
  
• StoreWars (ngxs, redux, vuex) / , (Cinimex)
  

आओ, यह दिलचस्प होगा!