मुझे मतदान पसंद है! क्या मैं? हाँ! क्या मैं? हाँ! क्या मैं? हाँ! क्या मैं अभी भी? हाँ! अभी का क्या? हाँ!
जैसा कि दूसरों ने उल्लेख किया है, यह अविश्वसनीय रूप से अक्षम हो सकता है यदि आप केवल एक ही अपरिवर्तित स्थिति को वापस लाने के लिए मतदान कर रहे हैं। यह सीपीयू साइकिल जलाने और मोबाइल उपकरणों पर बैटरी जीवन को कम करने के लिए एक नुस्खा है। निश्चित रूप से यह बेकार नहीं है यदि आप एक नया और सार्थक राज्य प्राप्त कर रहे हैं, जो हर बार वांछित से अधिक तेज़ दर पर नहीं होता है।
लेकिन मुझे मतदान पसंद है इसका मुख्य कारण इसकी सरलता और पूर्वानुमान योग्य प्रकृति है। आप कोड के माध्यम से पता लगा सकते हैं और आसानी से देख सकते हैं कि कब और कहां चीजें होने जा रही हैं, और किस धागे में। यदि, सैद्धांतिक रूप से, हम एक ऐसी दुनिया में रहते थे जहाँ मतदान एक नगण्य अपशिष्ट था (यद्यपि वास्तविकता इससे बहुत दूर है), तो मेरा मानना है कि यह कोड को जबरदस्त बनाए रखने को सरल करेगा। और यह कि मुझे इस मामले में नहीं होना चाहिए, भले ही मुझे यह देखने को मिले कि अगर हम प्रदर्शन की अवहेलना कर सकते हैं, तो मतदान और खींचने का लाभ होगा।
जब मैंने डॉस युग में प्रोग्रामिंग शुरू की, तो मेरे छोटे खेल मतदान के आसपास घूमते थे। मैंने कुछ असेंबली कोड को एक किताब से कॉपी किया था जिसे मैंने बमुश्किल कीबोर्ड इंटरप्ट से संबंधित समझा था और इसे कीबोर्ड स्टेट्स का एक बफर स्टोर किया था, जिस बिंदु पर मेरा मुख्य लूप हमेशा मतदान करता था। क्या अप की चाबी नीचे है? नहीं। क्या अप की चाबी नीचे है? नहीं। अभी के बारे में कैसे? नहीं। अभी व? हाँ। ठीक है, खिलाड़ी को स्थानांतरित करें।
और अविश्वसनीय रूप से बेकार होने पर, मैंने पाया कि मल्टी-टास्किंग और ईवेंट-चालित प्रोग्रामिंग के इन दिनों की तुलना में तर्क करना इतना आसान है। मुझे पता था कि हर समय कब और कहां चीजें होंगी और हिचकी के बिना फ्रेम दर को स्थिर और अनुमानित रखना आसान था।
इसलिए तब से मैं हमेशा सीपीयू चक्रों को जलाने के बिना कुछ लाभों और पूर्वानुमानों को प्राप्त करने का एक तरीका खोजने की कोशिश कर रहा हूं, जैसे कि थ्रेड को अधिसूचित करने के लिए स्थिति चर का उपयोग करने के लिए जिस बिंदु पर वे नए राज्य को खींच सकते हैं, उनकी बात करो, और सोने के लिए वापस जाने के लिए फिर से अधिसूचित होने की प्रतीक्षा कर रहे हैं।
और किसी तरह मुझे घटना कतारें कम से कम पर्यवेक्षक पैटर्न के साथ काम करने के लिए बहुत आसान लगती हैं, भले ही वे अभी भी यह भविष्यवाणी करना इतना आसान नहीं बनाते हैं कि आप कहां जा रहे हैं या क्या हो रहा है। वे कम से कम सिस्टम में कुछ प्रमुख क्षेत्रों में इवेंट हैंडलिंग कंट्रोल फ्लो को केंद्रीकृत करते हैं और हमेशा एक फ़ंक्शन से कहीं और पूरी तरह से दूरस्थ और अप्रत्याशित रूप से अप्रत्याशित रूप से सभी को संभालते हुए केंद्रीय इवेंट हैंडलिंग थ्रेड के बाहर एक ही धागे में उन घटनाओं को संभालते हैं। इसलिए डायकोटॉमी को हमेशा पर्यवेक्षकों और मतदान के बीच नहीं होना चाहिए। घटना की कतारें एक मध्य मैदान की तरह होती हैं।
लेकिन हाँ, किसी तरह मुझे यह बहुत आसान लगता है कि उन प्रणालियों के बारे में जो ऐसी चीजें करते हैं जो उस तरह के पूर्वानुमानित नियंत्रण प्रवाह के करीब होती हैं जो मेरे पास तब हुआ करती थीं जब मैं उम्र से पहले मतदान कर रहा था, जबकि काम पर होने की प्रवृत्ति का प्रतिकार कर रहा था ऐसे समय जब कोई राज्य परिवर्तन नहीं हुआ है। तो वहाँ है कि लाभ अगर आप इसे एक तरह से कर सकते हैं कि हालत चर के साथ की तरह अनावश्यक रूप से सीपीयू चक्र जल नहीं है।
सजातीय पाश
ठीक है, मुझे एक बढ़िया टिप्पणी मिली Josh Caswellजो मेरे उत्तर में कुछ नासमझी की ओर इशारा करती है:
"थ्रेड को सूचित करने के लिए स्थिति चर का उपयोग करना पसंद है" एक घटना-आधारित / पर्यवेक्षक की तरह लगता है, मतदान नहीं
तकनीकी रूप से स्थिति चर स्वयं ही थ्रेड को जागृत / अधिसूचित करने के लिए पर्यवेक्षक पैटर्न को लागू कर रहा है, इसलिए कॉल करने के लिए कि "मतदान" शायद अविश्वसनीय रूप से भ्रामक होगा। लेकिन मुझे लगता है कि यह एक समान लाभ प्रदान करता है जिसे मैंने डॉस दिनों से मतदान के रूप में पाया (बस नियंत्रण प्रवाह और पूर्वानुमान के संदर्भ में)। मैं इसे बेहतर तरीके से समझाने की कोशिश करूंगा।
मैंने उन दिनों में जो अपील की थी, वह यह था कि आप कोड के एक खंड को देख सकते हैं या इसके माध्यम से पता लगा सकते हैं और कह सकते हैं, "ठीक है, यह पूरा खंड कीबोर्ड की घटनाओं को संभालने के लिए समर्पित है। कोड के इस अनुभाग में और कुछ नहीं होने जा रहा है। और मुझे पता है कि पहले क्या होने जा रहा है, और मुझे पता है कि वास्तव में क्या होने वाला है (भौतिकी और प्रतिपादन, जैसे)। " कीबोर्ड राज्यों के मतदान ने आपको इस प्रकार के नियंत्रण प्रवाह के केंद्रीकरण के रूप में दिया, जहाँ तक कि इस बाहरी घटना के जवाब में क्या होना चाहिए। हमने तुरंत इस बाहरी घटना का जवाब नहीं दिया। हमने अपनी सुविधानुसार इसका जवाब दिया।
जब हम एक ऑब्जर्वर पैटर्न पर आधारित एक पुश-आधारित प्रणाली का उपयोग करते हैं, तो हम अक्सर उन लाभों को खो देते हैं। एक नियंत्रण का आकार परिवर्तन हो सकता है जो एक आकार बदलने वाली घटना को ट्रिगर करता है। जब हम इसके माध्यम से पता लगाते हैं, तो हम पाते हैं कि हम विदेशी नियंत्रण के अंदर हैं जो अपने आकार में बहुत सी कस्टम चीजें करता है जो अधिक घटनाओं को ट्रिगर करता है। हम अंत में इन सभी कैस्केडिंग घटनाओं में पूरी तरह से आश्चर्यचकित हो जाते हैं जैसे हम सिस्टम में समाप्त होते हैं। इसके अलावा, हम पा सकते हैं कि यह सब किसी भी दिए गए धागे में भी लगातार नहीं होता है क्योंकि थ्रेड A यहाँ एक नियंत्रण का आकार बदल सकता है जबकि थ्रेड B बाद में एक नियंत्रण का भी आकार लेता है। इसलिए मुझे हमेशा यह बहुत मुश्किल लगता था कि यह बता पाना कितना मुश्किल है कि यह भविष्यवाणी करना मुश्किल है कि सब कुछ होता है और साथ ही साथ क्या होगा।
घटना की कतार मेरे लिए थोड़ा सा सरल है क्योंकि मैं इसे सरल बनाता हूं जहां ये सभी चीजें कम से कम एक थ्रेड स्तर पर होती हैं। हालाँकि, कई असमान चीजें हो सकती हैं। एक ईवेंट कतार में प्रोसेस करने के लिए ईवेंट का एक समान मिश्रण हो सकता है, और हर एक अभी भी हमें आश्चर्यचकित कर सकता है कि क्या हुआ कि घटनाओं का कैस्केड क्या है, जिस क्रम में वे संसाधित किए गए थे, और हम कोडबेस में सभी जगह उछलते हुए कैसे समाप्त होते हैं ।
मैं मतदान के लिए "निकटतम" पर विचार कर रहा हूं, एक घटना कतार का उपयोग नहीं करेगा लेकिन एक बहुत ही सजातीय प्रकार के प्रसंस्करण को बाधित करेगा। एक PaintSystemस्थिति चर के माध्यम से सतर्क किया जा सकता है कि एक खिड़की के कुछ ग्रिड कोशिकाओं को पुन: पेश करने के लिए पेंटिंग का काम है, जिस बिंदु पर यह कोशिकाओं के माध्यम से एक सरल अनुक्रमिक लूप करता है और उचित जेड-ऑर्डर में इसके अंदर सब कुछ दोहराता है। एक सेल में रहने वाले प्रत्येक विजेट में पेंट ईवेंट को ट्रिगर करने के लिए यहां अप्रत्यक्ष / गतिशील प्रेषण कॉल करने का एक स्तर हो सकता है, जिसे पुन: अंकित करने की आवश्यकता होती है, लेकिन यह है - अप्रत्यक्ष कॉल की सिर्फ एक परत। स्थिति चर पर्यवेक्षक पैटर्न का उपयोग करता है PaintSystemताकि यह सचेत किया जा सके कि उसके पास काम करने के लिए है, लेकिन यह उससे अधिक और कुछ भी निर्दिष्ट नहीं करता है, औरPaintSystemउस बिंदु पर एक समान, बहुत ही सजातीय कार्य के लिए समर्पित है। जब हम PaintSystem'sकोड के माध्यम से डिबगिंग और ट्रेस कर रहे होते हैं , तो हम जानते हैं कि पेंटिंग के अलावा और कुछ नहीं होगा।
तो यह ज्यादातर सिस्टम को प्राप्त करने के बारे में है, जहां आपके पास ये चीजें हैं जो डेटा पर सजातीय छोरों का प्रदर्शन करती हैं, गैर-सजातीय छोरों के बजाय उस पर एक बहुत ही विलक्षण जिम्मेदारी को लागू करने के लिए कई जिम्मेदारियों को पूरा करने वाले डेटा के असमान प्रकारों पर जैसे कि हम इवेंट कतार प्रसंस्करण के लिए प्राप्त कर सकते हैं।
हम इस प्रकार की चीज़ के लिए लक्ष्य कर रहे हैं:
when there's work to do:
for each thing:
apply a very specific and uniform operation to the thing
विरोध के रूप में:
when one specific event happens:
do something with relevant thing
in relevant thing's event:
do some more things
in thing1's triggered by thing's event:
do some more things
in thing2's event triggerd by thing's event:
do some more things:
in thing3's event triggered by thing2's event:
do some more things
in thing4's event triggered by thing1's event:
cause a side effect which shouldn't be happening
in this order or from this thread.
इत्यादि। और इसके लिए प्रति कार्य एक धागा नहीं होना चाहिए। एक धागा GUI नियंत्रण के लिए लेआउट (आकार बदलने / पुन: प्रस्तुत करने) को लागू कर सकता है और उन्हें फिर से लिख सकता है, लेकिन यह कीबोर्ड या माउस क्लिक को संभाल नहीं सकता है। तो आप इसे एक घटना कतार की समरूपता में सुधार के रूप में देख सकते हैं। लेकिन हमें किसी घटना कतार और इंटरलेवे का आकार बदलने और पेंटिंग कार्यों का उपयोग करने की आवश्यकता नहीं है। हम ऐसा कर सकते हैं:
in thread dedicated to layout and painting:
when there's work to do:
for each widget that needs resizing/reposition:
resize/reposition thing to target size/position
mark appropriate grid cells as needing repainting
for each grid cell that needs repainting:
repaint cell
go back to sleep
इसलिए उपर्युक्त दृष्टिकोण केवल थ्रेड को सूचित करने के लिए एक कंडीशन वैरिएबल का उपयोग करता है जब काम करने के लिए होता है, लेकिन यह विभिन्न प्रकार के ईवेंट को इंटरलीव नहीं करता है (एक लूप में आकार दें, दूसरे लूप में पेंट करें, दोनों का मिश्रण नहीं) और यह doesn ' यह बताने के लिए कि क्या कार्य ठीक है जिसे करने की आवश्यकता है (थ्रेड "पता चलता है" जो कि ईसीएस के सिस्टम-व्यापी राज्यों को देखकर जागने की आवश्यकता है)। प्रत्येक लूप जो करता है वह तब प्रकृति में बहुत सजातीय होता है, जिससे उस क्रम के बारे में तर्क करना आसान हो जाता है जिसमें सब कुछ होता है।
मुझे यकीन नहीं है कि इस प्रकार के दृष्टिकोण को क्या कहा जाए। मैंने अन्य GUI इंजनों को ऐसा करते नहीं देखा है और यह मेरा अपना विदेशी दृष्टिकोण है। लेकिन इससे पहले कि जब मैंने पर्यवेक्षकों या ईवेंट कतारों का उपयोग करके मल्टीथ्रेडेड जीयूआई फ्रेमवर्क को लागू करने की कोशिश की, तो मुझे इसे डिबग करने में काफी कठिनाई हुई और कुछ अस्पष्ट दौड़ की स्थिति और गतिरोध में भी भाग गया कि मैं एक तरह से ठीक करने के लिए स्मार्ट नहीं था जिससे मुझे आत्मविश्वास महसूस हुआ समाधान के बारे में (कुछ लोग ऐसा करने में सक्षम हो सकते हैं लेकिन मैं बहुत चालाक नहीं हूं)। मेरा पहला पुनरावृत्ति डिज़ाइन बस एक सिग्नल के माध्यम से सीधे एक स्लॉट कहलाता है और कुछ स्लॉट्स फिर एस्किंस काम करने के लिए अन्य थ्रेड्स को स्पॉन करेंगे, और यह कारण के लिए सबसे कठिन था और मैं दौड़ की स्थिति और गतिरोध पर ट्रिप कर रहा था। दूसरा पुनरावृत्ति एक घटना कतार का उपयोग करता है और उस कारण के लिए थोड़ा आसान था, लेकिन मेरे दिमाग के लिए इतना आसान नहीं है कि मैं इसे अभी भी अस्पष्ट गतिरोध और दौड़ में शामिल करूं। तीसरे और अंतिम पुनरावृत्ति ने ऊपर वर्णित दृष्टिकोण का उपयोग किया, और अंत में जिसने मुझे एक मल्टीथ्रेडेड जीयूआई फ्रेमवर्क बनाने की अनुमति दी जो कि मेरे जैसे एक गूंगा सिंपलटन भी सही तरीके से लागू कर सके।
तब इस प्रकार की अंतिम बहु-स्तरीय GUI डिज़ाइन ने मुझे कुछ और चीज़ों के साथ आने की अनुमति दी, जो कि कारण के बारे में बहुत आसान थी और उन प्रकार की गलतियों से बचने के लिए जिन्हें मैंने बनाने की कोशिश की थी, और उनमें से एक कारण मुझे इसके बारे में तर्क करने में बहुत आसान लगा। कम से कम इन सजातीय छोरों की वजह से है और कैसे वे थोड़े समय के लिए नियंत्रण प्रवाह से मिलते जुलते थे जब मैं DOS दिनों में मतदान कर रहा था (भले ही यह वास्तव में मतदान नहीं है और केवल काम कर रहा है जब वहां काम करना है)। यह विचार संभव था कि घटना से निपटने वाले मॉडल से दूर चला जाए जो गैर-सजातीय छोरों, गैर-सजातीय दुष्प्रभावों, गैर-सजातीय नियंत्रण प्रवाह, और समरूप डेटा पर समान रूप से काम कर रहे सजातीय छोरों की दिशा में अधिक से अधिक काम करने और अलग-थलग करने के लिए है। और इस तरह से साइड इफेक्ट को एकजुट करना कि "क्या" पर ध्यान केंद्रित करना आसान हो गया