हैलो, मेरा नाम दिमित्री कार्लोव्स्की है और मैं ... बेरोजगार। इसलिए, मेरे पास संगीत, खेल, रचनात्मकता, भाषाएं, जेएस-सम्मेलन और कंप्यूटर विज्ञान खेलने के लिए बहुत खाली समय है। मैं आपको कई मिलीसेकंड की छोटी $mol_fiber में लंबी गणना के अर्ध-स्वचालित विभाजन के क्षेत्र में नवीनतम शोध के बारे में बताता हूं, जिसके परिणामस्वरूप लघु पुस्तकालय $mol_fiber । लेकिन पहले, हम उन समस्याओं को रेखांकित करते हैं जिन्हें हम हल करेंगे।

यह होलीजेएस 2018 पाइटर पर एपॉनाम के प्रदर्शन का एक पाठ संस्करण है। आप इसे या तो एक लेख के रूप में पढ़ सकते हैं , या इसे प्रस्तुति इंटरफ़ेस में खोल सकते हैं , या एक वीडियो देख सकते हैं ।

मुद्दा: कम जवाबदेही

यदि हम प्रति सेकंड 60 फ्रेम स्थिर करना चाहते हैं, तो हमारे पास सभी काम करने के लिए केवल 16 मिलीसेकंड की एक ट्रिफ़ल है, जिसमें ब्राउज़र स्क्रीन पर परिणाम दिखाने के लिए क्या करता है।

लेकिन क्या होगा अगर हम प्रवाह को अधिक समय तक लेते हैं? तब उपयोगकर्ता एक लैगिंग इंटरफ़ेस का पालन करेगा, एनीमेशन को बाधित करेगा और यूएक्स गिरावट की तरह होगा।

मुद्दा: कोई बच नहीं

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

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

मैं तेज हूं और मैं इसे जानता हूं

लेकिन क्या होगा अगर हमारा काम एक नहीं, बल्कि कई, लेकिन एक धारा हो? कल्पना करें कि आप अपने ताजे खरीदे हुए पीले कमल पर गाड़ी चलाते हैं और रेलवे क्रॉसिंग तक जाते हैं। जब यह मुफ़्त है, तो आप इसे एक दूसरे विभाजन में पर्ची कर सकते हैं। लेकिन ..

समस्या: कोई संगति नहीं

जब क्रॉसिंग पर एक किलोमीटर ट्रेन का कब्जा होता है, तो आपको खड़े होकर दस मिनट इंतजार करना पड़ता है। इसके लिए नहीं कि आपने स्पोर्ट्स कार खरीदी है, है ना?

और अगर यह ट्रेन प्रत्येक 100 मीटर की 10 ट्रेनों में विभाजित हो जाती है और उनके बीच फिसलने में कई मिनट लगेंगे तो यह कितना अच्छा होगा! आपको तब इतनी देर नहीं होगी।

तो अब जेएस दुनिया में इन समस्याओं का समाधान क्या है?

समाधान: श्रमिक

पहली बात जो मन में आती है: चलो बस सभी जटिल गणनाओं को एक अलग धागे में डालते हैं? ऐसा करने के लिए, हमारे पास WebWorkers के लिए एक तंत्र है।

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

श्रमिक: मुद्दे: (डी) सीरियल

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

श्रमिक: मुद्दे: केवल अतुल्यकालिक

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

श्रमिक: मुद्दे: सीमित एपीआई

कार्यकर्ताओं में निम्नलिखित एपीआई हमारे लिए उपलब्ध नहीं हैं।

• डोम, सीएसएसओएम
• कैनवास
• जियोलोकेशन
• इतिहास और स्थान
• HTTP अनुरोधों को सिंक करें
• XMLHttpRequest.responseXML
• खिड़की

श्रमिक: मुद्दे: रद्द नहीं कर सकते

और फिर, हमारे पास वोकर में गणना को रोकने का कोई तरीका नहीं है।

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

समाधान: रिएक्ट फाइबर

निश्चित रूप से कई सुने हुए फेसबुक ने वीरतापूर्ण रूप से रिएक्ट को फिर से लिखा, एक विशेष अनुसूचक द्वारा शुरू किए गए छोटे कार्यों के एक समूह में सभी गणनाओं को तोड़ दिया।

मैं इसके कार्यान्वयन के विवरण में नहीं जाऊंगा, क्योंकि यह एक अलग विषय है। मैं केवल कुछ विशेषताओं पर ध्यान दूंगा, जिनकी वजह से यह आपके अनुरूप नहीं हो सकता है ..

रिएक्ट फाइबर: आवश्यक प्रतिक्रिया

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

रिएक्ट फाइबर: केवल प्रतिपादन

प्रतिक्रिया - केवल रेंडरिंग परत को कवर करता है। आवेदन के अन्य सभी परतों को बिना किसी परिमाण के छोड़ दिया जाता है।

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

प्रतिक्रिया फाइबर: मात्रा का ठहराव अक्षम है

परिमाणीकरण के लिए समर्थित समर्थन के बावजूद, यह अभी भी डिफ़ॉल्ट रूप से बंद है, क्योंकि यह पिछड़े संगतता को तोड़ता है।

प्रतिक्रिया में परिमाणीकरण अभी भी एक प्रयोगात्मक चीज है। सावधान!

रिएक्ट फाइबर: डीबग दर्द है

जब आप परिमाणीकरण चालू करते हैं, तो कॉलस्टैक आपके कोड से मेल नहीं खाता है, जो डीबगिंग को बहुत जटिल करता है। लेकिन हम इस मुद्दे पर लौटेंगे।

समाधान: परिमाणीकरण

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

ऊपर आप एक लंबी गणना देखते हैं जिसने पूरी दुनिया को 100ms से अधिक रोक दिया। और नीचे से - एक ही गणना, लेकिन लगभग 16ms के समय के स्लाइस में टूट गई, जिसने औसतन 60 फ्रेम प्रति सेकंड दिया। चूँकि हम आम तौर पर यह नहीं जानते हैं कि गणना में कितना समय लगेगा, इसलिए हम इसे मैन्युअल रूप से 16ms के टुकड़ों में अग्रिम रूप से नहीं तोड़ सकते हैं। इसलिए, हमें किसी प्रकार के रनटाइम तंत्र की आवश्यकता होती है जो कार्य को पूरा करने में लगने वाले समय को मापता है और जब क्वांटम पार हो जाता है, जो अगले एनीमेशन फ्रेम तक निष्पादन को रोक देता है। आइए, इस तरह के निलंबित कार्यों को लागू करने के लिए हमारे पास क्या तंत्र हैं, इसके बारे में सोचें।

कंसीलर: फाइबर - स्टैकफुल कोरटाइन

गो और डी जैसी भाषाओं में "एक स्टैक के साथ कोरटाइन" के रूप में इस तरह के एक मुहावरे हैं, यह एक "फाइबर" या "फाइबर" भी है।

 import { Future } from 'node-fibers' const one = ()=> Future.wait( future => setTimeout( future.return ) ) const two = ()=> one() + 1 const three = ()=> two() + 1 const four = ()=> three() + 1 Future.task( four ).detach() 

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

फाइबर का उपयोग करना काफी सुविधाजनक है, लेकिन उन्हें समर्थन देने के लिए, आपको रनटाइम समर्थन की आवश्यकता होती है, जो कि अधिकांश जेएस दुभाषियों के पास नहीं है। हालाँकि, NodeJS के लिए एक देशी node-fibers एक्सटेंशन है जो इस समर्थन को जोड़ता है। दुर्भाग्य से, कोई भी ब्राउज़र किसी भी ब्राउज़र में उपलब्ध नहीं है।

कंसीडर: FSM - स्टैकलेस कोरआउट्स

C # और अब JS जैसी भाषाओं में "स्टैकलेस कॉरआउट्स" या "एसिंक्रोनस फ़ंक्शंस" का समर्थन है। इस तरह के फ़ंक्शन हुड के तहत एक राज्य मशीन हैं और स्टैक के बारे में कुछ भी नहीं जानते हैं, इसलिए आपको उन्हें विशेष कीवर्ड "एसिंक्स" के साथ चिह्नित करना होगा, और उन स्थानों पर जहां वे रोक सकते हैं - "प्रतीक्षा"।

 const one = ()=> new Promise( done => setTimeout( done ) ) const two = async ()=> ( await one() ) + 1 const three = async ()=> ( await two() ) + 1 const four = async ()=> ( await three() ) + 1 four() 

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

Concurrency: अर्ध-तंतु - पुनरारंभ

आइए फाइबर के समान कुछ करने की कोशिश करें, केवल उन विशेषताओं का उपयोग करके जो किसी भी आधुनिक ब्राउज़र में हमारे लिए उपलब्ध हैं ।।

 import { $mol_fiber_async , $mol_fiber_start } from 'mol_fiber/web' const one = ()=> $mol_fiber_async( back => setTimeout( back ) ) const two = ()=> one() + 1 const three = ()=> two() + 1 const four = ()=> three() + 1 $mol_fiber_start( four ) 

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

आंकड़े

यह दिखाने के लिए कि छद्म फाइबर कैसे काम करते हैं, हम एक मुश्किल कोड लिखेंगे।

आइए कल्पना करें कि यहां step फ़ंक्शन कंसोल को कुछ लिखता है और 20ms के लिए कुछ अन्य कड़ी मेहनत करता है। और walk फंक्शन पूरी प्रक्रिया को लॉग करते हुए दो बार step कहता है। बीच में, यह दिखाएगा कि अब कंसोल में क्या प्रदर्शित किया गया है। और दाईं ओर स्यूडोफाइबर वृक्ष की अवस्था है।

$ mol_fiber: कोई मात्राकरण नहीं

आइए इस कोड को चलाते हैं और देखते हैं कि क्या होता है ..

अब तक, सब कुछ सरल और स्पष्ट है। बेशक, छद्म फाइबर पेड़ शामिल नहीं है। और सब कुछ ठीक हो जाएगा, लेकिन यह कोड 40 एमएस से अधिक के लिए निष्पादित किया जाता है, जो बेकार है।

$ mol_fiber: पहले कैश

चलो दोनों कार्यों को एक विशेष आवरण में लपेटते हैं जो इसे छद्म फाइबर में चलाता है और देखें कि क्या होता है ।।

यहां यह इस तथ्य पर ध्यान देने योग्य है कि walk फाइबर के अंदर one फ़ंक्शन को कॉल करने के प्रत्येक स्थान के लिए, एक अलग फाइबर बनाया गया था। पहली कॉल का परिणाम कैश किया गया था, लेकिन दूसरे के बजाय, Promise को फेंक दिया गया था, क्योंकि हमने अपना समय टुकड़ा समाप्त कर दिया था।

$ mol_fiber: कैश दूसरा

पहले फ्रेम में फेंक दें, Promise अगले में स्वचालित रूप से हल हो जाएगा, जिससे walk फाइबर का पुनरारंभ होगा।

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

तो first begin एक बार प्रिंट क्यों first begin first done और first done दो first done ? यह सब आलस्य के बारे में है। console.log - नॉन-आइडम्पोटेंट ऑपरेशन, आप इसे कितनी बार कॉल करते हैं, इसलिए कई बार यह कंसोल में एक प्रविष्टि जोड़ देगा। लेकिन जो फाइबर किसी अन्य फाइबर में निष्पादित हो रहा है, वह बेकार है, यह केवल पहली कॉल पर हैंडल को निष्पादित करता है, और बाद में किसी भी अतिरिक्त साइड इफेक्ट के लिए अग्रणी, कैश से तुरंत परिणाम देता है।

$ mol_fiber: पहले बेरोजगारी

चलो एक फाइबर में console.log लपेटते हैं, जिससे यह बेकार हो जाता है, और देखें कि कार्यक्रम कैसे व्यवहार करता है ..

जैसा कि आप देख सकते हैं, अब फाइबर ट्री में हमारे पास log फ़ंक्शन के लिए प्रत्येक कॉल के लिए प्रविष्टियां हैं।

$ mol_fiber: idempotence दूसरा

walk फाइबर के अगले पुनरारंभ में, log फ़ंक्शन को बार-बार कॉल करने से वास्तविक console.log को कॉल नहीं होता है। लेकिन जैसे ही हम एक खाली कैश के साथ फाइबर के निष्पादन को प्राप्त करते हैं, console.log कॉल फिर console.log शुरू हो console.log ।

कृपया ध्यान दें कि कंसोल में अब हम कुछ भी नहीं दिखाते हैं - बिना किसी फाइबर और परिमाण के तुल्यकालिक कोड में जो प्रदर्शित किया जाएगा।

$ मोल_फाइबर: ब्रेक

कैसे होती है गणना में बाधा? क्वांटम की शुरुआत में, एक समय सीमा निर्धारित की जाती है। और प्रत्येक फाइबर को शुरू करने से पहले, यह जाँच लिया जाता है कि क्या हम उस तक पहुँच गए हैं। और यदि आप पहुंचते हैं, तो Promise है, जो अगले फ्रेम में हल हो जाता है और एक नई मात्रा शुरू करता है ।।

 if( Date.now() > $mol_fiber.deadline ) { throw new Promise( $mol_fiber.schedule ) } 

$ mol_fiber: समय सीमा

क्वांटम के लिए समय सीमा निर्धारित करना आसान है। वर्तमान समय में 8 मिलीसेकंड जोड़े जाते हैं। ठीक 8 क्यों, क्योंकि शॉट तैयार करने के लिए 16 जितने हैं? तथ्य यह है कि हम पहले से नहीं जानते हैं कि ब्राउज़र को कितनी देर तक रेंडर करने की आवश्यकता होगी, इसलिए हमें इसे काम करने के लिए कुछ समय छोड़ने की आवश्यकता है। लेकिन कभी-कभी ऐसा होता है कि ब्राउज़र को कुछ भी रेंडर करने की आवश्यकता नहीं होती है, और फिर 8ms क्वांटा के साथ हम एक ही फ्रेम में एक और क्वांटम सम्मिलित कर सकते हैं, जो न्यूनतम प्रोसेसर डाउनटाइम के साथ क्वांटा की एक तंग पैकिंग देगा।

 const now = Date.now() const quant = 8 const elapsed = Math.max( 0 , now - $mol_fiber.deadline ) const resistance = Math.min( elapsed , 1000 ) / 10 // 0 .. 100 ms $mol_fiber.deadline = now + quant + resistence 

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

डिबग: कोशिश / पकड़

चूंकि हम डिबगिंग के बारे में बात कर रहे हैं, आपको क्या लगता है, इस कोड के किस स्थान पर डीबगर बंद हो जाता है?

 function foo() { throw new Error( 'Something wrong' ) // [1] } try { foo() } catch( error ) { handle( error ) throw error // [2] } 

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

डिबग: अखंडित घटनाएँ

आमतौर पर, रनटाइम एक वैश्विक घटना प्रदान करता है जो प्रत्येक अनकैप्ड अपवाद के लिए होती है।

 function foo() { throw new Error( 'Something wrong' ) } window.addEventListener( 'error' , event => handle( event.error ) ) foo() 

बोझिलता के अलावा, इस समाधान में ऐसी खामी है कि सभी अपवाद यहां आते हैं और यह समझना मुश्किल है कि यह घटना किस फाइबर और फाइबर से हुई है।

डिबग: वादा

अपवादों को संभालने के लिए वादे सबसे अच्छे तरीके हैं।

 function foo() { throw new Error( 'Something wrong' ) } new Promise( ()=> { foo() } ).catch( error => handle( error ) ) 

वादा करने के लिए पारित फ़ंक्शन को तुरंत, सिंक्रोनस कहा जाता है, लेकिन अपवाद नहीं पकड़ा गया है और सुरक्षित रूप से डिबगर को इसकी घटना के स्थान पर रोक देता है। थोड़ी देर बाद, एसिंक्रोनस रूप से, यह पहले से ही त्रुटि हैंडलर को कॉल करता है, जिसमें हम जानते हैं कि किस फाइबर ने विफलता दी और कौन सी विफलता। यह ठीक $ mol_fiber में प्रयुक्त तंत्र है।

स्टैक ट्रेस: ​​रिएक्शन फाइबर

आइए एक नजर डालते हैं स्टैक ट्रेस में आपको रिएक्ट फाइबर से ..

जैसा कि आप देख सकते हैं, हमें बहुत सी प्रतिक्रिया मिलती है। यहां उपयोगी से, केवल अपवाद के बिंदु और घटकों के नाम पदानुक्रम में अधिक हैं। बहुत कुछ नहीं।

स्टैक ट्रेस: ​​$ mol_fiber

$ Mol_fiber में, हमें बहुत अधिक उपयोगी स्टैक ट्रेस मिलता है: कोई हिम्मत नहीं, केवल आवेदन कोड में विशिष्ट बिंदु जिसके माध्यम से यह एक अपवाद आया।

यह आंतों के मूल ढेर, वादों और स्वचालित हटाने के माध्यम से प्राप्त किया जाता है। यदि आप चाहें, तो आप स्क्रीनशॉट में, कंसोल में त्रुटि का विस्तार कर सकते हैं, और हिम्मत देख सकते हैं, लेकिन दिलचस्प कुछ भी नहीं है।

$ mol_fiber: संभाल

तो, एक क्वांटम को बाधित करने के लिए, प्रोमिस को फेंक दिया जाता है।

 limit() { if( Date.now() > $mol_fiber.deadline ) { throw new Promise( $mol_fiber.schedule ) } // ... } 

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

 fail( error : Error ) { if( error instanceof Promise ) { const listener = ()=> self.start() return error.then( listener , listener ) } // ... } 

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

$ mol_fiber: फ़ंक्शन

किसी भी सिंक्रोनस फ़ंक्शन को एक बेकार फाइबर में बदलने के लिए, बस इसे $mol_fiber_func में $mol_fiber_func ।

 import { $mol_fiber_func as fiberize } from 'mol_fiber/web' const log = fiberize( console.log ) export const main = fiberize( ()=> { log( getData( 'goo.gl' ).data ) } ) 

यहां हमने console.log इम्पोटेंट बनाया, और main ने डाउनलोड के लिए इंतजार करते हुए बीच में रुकना सिखाया।

$ mol_fiber: त्रुटि से निपटने

लेकिन अपवादों का जवाब कैसे दिया जाए अगर हम try-catch का उपयोग नहीं करना चाहते हैं? फिर हम $mol_fiber_catch साथ त्रुटि हैंडलर को पंजीकृत कर सकते हैं ...

 import { $mol_fiber_func as fiberize , $mol_fiber_catch as onError } from 'mol_fiber' const getConfig = fiberize( ()=> { onError( error => ({ user : 'Anonymous' }) ) return getData( '/config' ).data } ) 

यदि हम इसमें त्रुटि से कुछ अलग लौटाते हैं, तो यह वर्तमान फाइबर का परिणाम होगा। इस उदाहरण में, यदि सर्वर से कॉन्फ़िगरेशन को डाउनलोड करना संभव नहीं है, तो getConfig फ़ंक्शन डिफ़ॉल्ट रूप से getConfig को वापस कर देगा।

$ mol_fiber: विधियाँ

बेशक, आप न केवल फ़ंक्शन लपेट सकते हैं, बल्कि एक डेकोरेटर का उपयोग करने के तरीके भी कर सकते हैं।

 import { $mol_fiber_method as action } from 'mol_fiber/web' export class Mover { @action move() { sendData( 'ya.ru' , getData( 'goo.gl' ) ) } } 

यहाँ, उदाहरण के लिए, हमने Google से डेटा अपलोड किया और इसे यैंडेक्स पर अपलोड किया।

$ mol_fiber: वादे

सर्वर से डेटा डाउनलोड करने के लिए, यह लेने के लिए पर्याप्त है, उदाहरण के लिए, एसिंक्रोनस फ़ंक्शन fetch और कलाई के एक फ्लिक के साथ इसे सिंक्रोनस में बदल देते हैं।

 import { $mol_fiber_sync as sync } from 'mol_fiber/web' export const getData = sync( fetch ) 

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

$ mol_fiber: अनुरोध रद्द करें

 import { $mol_fiber_async as async } from 'mol_fiber/web' function getData( uri : string ) : Response { return async( back => { var controller = new AbortController(); fetch( uri , { signal : controller.signal } ).then( back( res => res ) , back( error => { throw error } ) , ) return ()=> controller.abort() } ) } 

async आवरण के लिए दिया गया फ़ंक्शन केवल एक बार कॉल किया जाता है और back रैपर को इसे पास किया जाता है, जिसमें आपको कॉलबैक को लपेटने की आवश्यकता होती है। तदनुसार, इन कॉलबैक में, आपको या तो मूल्य वापस करना होगा या अपवाद फेंकना होगा। कॉलबैक का परिणाम जो भी हो, यह फाइबर का परिणाम भी होगा। कृपया ध्यान दें कि अंत में हम एक फ़ंक्शन लौटाते हैं जो फाइबर के समय से पहले विनाश के मामले में कहा जाएगा।

$ mol_fiber: प्रतिक्रिया रद्द करें

सर्वर साइड पर, क्लाइंट के गिर जाने पर गणना को रद्द करना भी उपयोगी हो सकता है। आइए midleware पर एक आवरण लागू करें जो एक फाइबर बनाएगा जिसमें मूल midleware चलेगा। , , , .

 import { $mol_fiber_make as Fiber } from 'mol_fiber' const middle_fiber = middleware => ( req , res ) => { const fiber = Fiber( ()=> middleware( req , res ) ) req.on( 'close' , ()=> fiber.destructor() ) fiber.start() } app.get( '/foo' , middle_fiber( ( req , res ) => { // do something } ) ) 

$mol_fiber: concurrency

, . , 3 : , , - ..

: , . . , , .

$mol_fiber: properties

, ..

Pros:

• Runtime support isn't required
• Can be cancelled at any time
• High FPS
• Concurrent execution
• Debug friendly
• ~ 3KB gzipped

Cons:

• Instrumentation is required
• All code should be idempotent
• Longer total execution

$mol_fiber — , . — , . , , . , , , , . , . .

Links

• nin-jin.imtqy.com/slides/fibers/ — this slides
• mol.js.org/fiber — $mol_fiber online demo
• github.com/eigenmethod/mol/tree/master/fiber — $mol_fiber documentation
• t.me/mam_mol — lovely $mol chat

Call back

: , , )

: , .

: . , .

: . , . , .

: , . , )

: , .

: - . , , .

: . , , .

: , . 16ms, ? 16 8 , 8, . , . , «».

: — . धन्यवाद!

: . , . !

: , . .

: , , , , , / , .

: , .

: .

: , . mol.

: , , . , , , .

: .

: , . , $mol, , .

: , , . — . .

: - , .

: $mol , . (pdf, ) , .

: , . , .

: , ) .

: . .

: In some places I missed what the reporter was saying. The conversation was about how to use the "Mola" library and "why?". But how it works remains a mystery for me.To smoke an source code is for the overhead.

: , .

: . , . . .

: : . - (, ). , : 16?

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