इवेंट लूप: Difference between revisions
(Created page with "कंप्यूटर विज्ञान में, इवेंट लूप एक प्रोग्रामिंग निर्माण या सॉफ...") |
|||
| Line 97: | Line 97: | ||
* | |||
* | |||
==बाहरी कड़ियाँ== | ==बाहरी कड़ियाँ== | ||
*[http://www.microsoft.com/msj/0795/dilascia/dilascia.aspx Meandering Through the Maze of MFC Message and Command Routing] | *[http://www.microsoft.com/msj/0795/dilascia/dilascia.aspx Meandering Through the Maze of MFC Message and Command Routing] | ||
Revision as of 12:11, 13 January 2023
कंप्यूटर विज्ञान में, इवेंट लूप एक प्रोग्रामिंग निर्माण या सॉफ्टवेयर डिजाइन पैटर्न है जो कंप्यूटर प्रोग्राम में घटना-संचालित प्रोग्रामिंग या संदेश पासिंग इंटरफ़ेस की प्रतीक्षा करता है और भेजता है। ईवेंट लूप कुछ आंतरिक या बाहरी ईवेंट प्रदाता (जो आम तौर पर किसी ईवेंट के आने तक अनुरोध को अवरुद्ध (कंप्यूटिंग) करता है) के लिए अनुरोध करके काम करता है, फिर संबंधित आयोजन प्रबंधकर्ता को कॉल करता है (इवेंट को डिस्पैच करता है)। ईवेंट लूप को कभी-कभी संदेश प्रेषक, संदेश लूप, संदेश पंप या रन लूप के रूप में भी जाना जाता है।
ईवेंट-लूप का उपयोग रिएक्टर पैटर्न के संयोजन के साथ किया जा सकता है, यदि ईवेंट प्रदाता #फ़ाइल इंटरफ़ेस का अनुसरण करता है, जिसे चुना जा सकता है या 'पोल' किया जा सकता है (यूनिक्स सिस्टम कॉल, वास्तविक मतदान नहीं (कंप्यूटर विज्ञान))। ईवेंट लूप लगभग हमेशा संदेश प्रवर्तक के साथ अतुल्यकालिक रूप से संचालित होता है।
जब इवेंट लूप प्रोग्राम के केंद्रीय नियंत्रण प्रवाह का निर्माण करता है, जैसा कि अक्सर होता है, इसे मेन लूप या मेन इवेंट लूप कहा जा सकता है। यह शीर्षक उपयुक्त है, क्योंकि इस तरह का इवेंट लूप कार्यक्रम के भीतर उच्चतम स्तर पर नियंत्रण रखता है।
संदेश गुजर रहा है
संदेश पंप को प्रोग्राम की संदेश कतार से संदेशों को 'पंप' करने के लिए कहा जाता है (असाइन किए गए और आमतौर पर अंतर्निहित ऑपरेटिंग सिस्टम के स्वामित्व वाले) प्रसंस्करण के लिए कार्यक्रम में। सख्त अर्थों में, एक इवेंट लूप अंतर-प्रक्रिया संचार को लागू करने के तरीकों में से एक है। वास्तव में, कई प्रणालियों में संदेश प्रसंस्करण मौजूद है, जिसमें मच कर्नेल का कर्नेल (कंप्यूटर विज्ञान) |कर्नेल-स्तर घटक शामिल है। इवेंट लूप सिस्टम की एक विशिष्ट कार्यान्वयन तकनीक है जो संदेश देना का उपयोग करती है।
वैकल्पिक डिजाइन
यह दृष्टिकोण कई अन्य विकल्पों के विपरीत है:
- परंपरागत रूप से, एक कार्यक्रम केवल एक बार चलता है, फिर समाप्त हो जाता है। कंप्यूटिंग के शुरुआती दिनों में इस प्रकार का कार्यक्रम बहुत आम था, और इसमें किसी भी प्रकार की उपयोगकर्ता अन्तरक्रियाशीलता का अभाव था। यह अभी भी अक्सर उपयोग किया जाता है, विशेष रूप से कमांड लाइन |कमांड-लाइन-संचालित प्रोग्राम के रूप में। किसी भी मापदंडों को पहले से सेट किया जाता है और प्रोग्राम शुरू होने पर एक ही बार में पास कर दिया जाता है।
- मेनू चालित डिजाइन। ये अभी भी एक मुख्य लूप पेश कर सकते हैं, लेकिन आमतौर पर सामान्य अर्थों में इवेंट-संचालित प्रोग्रामिंग के रूप में नहीं सोचा जाता है।Template:Citationneeded इसके बजाय, उपयोगकर्ता को विकल्पों के कभी-संकीर्ण सेट के साथ प्रस्तुत किया जाता है जब तक कि वे जो कार्य करना चाहते हैं वह एकमात्र विकल्प उपलब्ध नहीं है। मेनू के माध्यम से सीमित अन्तरक्रियाशीलता उपलब्ध है।
उपयोग
ग्राफिकल यूज़र इंटरफ़ेस की प्रबलता के कारण, अधिकांश आधुनिक अनुप्रयोगों में एक मुख्य लूप होता है। get_next_message() ई> रूटीन आमतौर पर ऑपरेटिंग सिस्टम द्वारा प्रदान किया जाता है, और संदेश उपलब्ध होने तक ब्लॉक (कंप्यूटिंग) किया जाता है। इस प्रकार, लूप केवल तभी दर्ज किया जाता है जब प्रक्रिया करने के लिए कुछ होता है।
समारोह मुख्य
प्रारंभ करें ()
जबकि संदेश! = छोड़ो
संदेश: = get_next_message ()
प्रक्रिया_संदेश (संदेश)
जबकि समाप्त करें
अंत समारोह
फ़ाइल इंटरफ़ेस
यूनिक्स के तहत, सब कुछ एक फ़ाइल प्रतिमान है जो स्वाभाविक रूप से फ़ाइल-आधारित ईवेंट लूप की ओर ले जाता है। फाइलों से पढ़ना और लिखना, अंतर-प्रक्रिया संचार, नेटवर्क संचार, और डिवाइस नियंत्रण सभी फ़ाइल I/O का उपयोग करके हासिल किए जाते हैं, फ़ाइल डिस्क्रिप्टर द्वारा पहचाने गए लक्ष्य के साथ। सेलेक्ट (यूनिक्स) और मतदान (यूनिक्स) सिस्टम कॉल फाइल डिस्क्रिप्टर के एक सेट को स्थिति में बदलाव के लिए मॉनिटर करने की अनुमति देते हैं, उदा। जब डेटा पढ़ने के लिए उपलब्ध हो जाता है।
उदाहरण के लिए, एक प्रोग्राम पर विचार करें जो एक निरंतर अद्यतन फ़ाइल से पढ़ता है और एक्स विंडो सिस्टम में इसकी सामग्री प्रदर्शित करता है, जो क्लाइंट के साथ सॉकेट (या तो यूनिक्स डोमेन सॉकेट या बर्कले सॉकेट ) पर संचार करता है: <वाक्यविन्यास लैंग = अजगर> डीईएफ़ मुख्य ():
file_fd = खुला (logfile.log)
x_fd = open_display ()
निर्माण_इंटरफेस ()
जबकि सच:
सूची, _, _ = चयन करें। चयन करें ([file_fd, x_fd], [], []):
अगर rlist में file_fd:
डेटा = file_fd.read ()
परिशिष्ट_to_प्रदर्शन (डेटा)
send_repaint_message ()
अगर rlist में x_fd:
प्रक्रिया_x_संदेश ()
</वाक्यविन्यास हाइलाइट>
संकेतों को संभालना
यूनिक्स में कुछ चीजों में से एक जो फ़ाइल इंटरफ़ेस के अनुरूप नहीं है, अतुल्यकालिक घटनाएँ (संकेत (कंप्यूटिंग) ) हैं। सिग्नल हैंडलर में सिग्नल प्राप्त होते हैं, कोड के छोटे, सीमित टुकड़े जो चलते हैं जबकि शेष कार्य निलंबित रहता है; यदि कार्य अवरुद्ध होने पर एक संकेत प्राप्त होता है और संभाला जाता है select(), लिनक्स में त्रुटि कोड के साथ चयन जल्दी वापस आ जाएगा; यदि कार्य CPU बाउंड होने के दौरान एक संकेत प्राप्त होता है, तो सिग्नल हैंडलर के वापस आने तक कार्य को निर्देशों के बीच निलंबित कर दिया जाएगा।
इस प्रकार संकेतों को संभालने का एक स्पष्ट तरीका सिग्नल संचालकों के लिए एक वैश्विक ध्वज सेट करना है और ध्वज के लिए इवेंट लूप की जांच तुरंत पहले और बाद में करना है। select() पुकारना; यदि यह सेट है, तो सिग्नल को उसी तरह से संभालें जैसे फ़ाइल डिस्क्रिप्टर पर ईवेंट के साथ। दुर्भाग्य से, यह दौड़ की स्थिति को जन्म देता है: यदि झंडे की जांच और कॉल करने के बीच तुरंत एक संकेत आता है select(), इसे तब तक संभाला नहीं जाएगा select() किसी अन्य कारण से लौटाता है (उदाहरण के लिए, निराश उपयोगकर्ता द्वारा बाधित किया जाना)।
POSIX द्वारा निकाला गया समाधान है pselect() कॉल, जो समान है select() लेकिन एक अतिरिक्त लेता है sigmask पैरामीटर, जो सिग्नल मास्क का वर्णन करता है। यह एप्लिकेशन को मुख्य कार्य में सिग्नल को मास्क करने की अनुमति देता है, फिर की अवधि के लिए मास्क को हटा दें select() कॉल ऐसे करें कि सिग्नल हैंडलर को केवल तभी बुलाया जाए जब एप्लिकेशन I/O बाध्य हो। हालाँकि, का कार्यान्वयन pselect() हमेशा विश्वसनीय नहीं रहे हैं; 2.6.16 से पहले के Linux के संस्करणों में a नहीं है pselect() सिस्टम कॉल,[1] glibc को एक ही दौड़ की स्थिति के लिए प्रवण विधि के माध्यम से इसका अनुकरण करने के लिए मजबूर करना pselect() बचने का इरादा है।
एक वैकल्पिक, अधिक पोर्टेबल समाधान, अतुल्यकालिक घटनाओं को स्व-पाइप चाल का उपयोग करके फ़ाइल-आधारित घटनाओं में परिवर्तित करना है,[2] जहां एक सिग्नल हैंडलर एक पाइप को एक बाइट लिखता है जिसके दूसरे सिरे की निगरानी की जाती है select() मुख्य कार्यक्रम में।[3] लिनक्स कर्नेल संस्करण 2.6.22 में, एक नया सिस्टम कॉल signalfd() जोड़ा गया, जो एक विशेष फाइल डिस्क्रिप्टर के माध्यम से सिग्नल प्राप्त करने की अनुमति देता है।
कार्यान्वयन
विंडोज़ अनुप्रयोग
Microsoft Windows ऑपरेटिंग सिस्टम पर, एक प्रक्रिया जो उपयोगकर्ता के साथ इंटरैक्ट करती है उसे आने वाले संदेशों को स्वीकार करना और प्रतिक्रिया देना चाहिए, जो उस प्रक्रिया में Microsoft Windows में संदेश लूप द्वारा लगभग अनिवार्य रूप से किया जाता है। विंडोज़ में, एक संदेश ऑपरेटिंग सिस्टम पर निर्मित और लगाए गए ईवेंट के बराबर होता है। एक घटना अन्य लोगों के बीच उपयोगकर्ता इंटरैक्शन, नेटवर्क ट्रैफ़िक, सिस्टम प्रोसेसिंग, टाइमर गतिविधि, इंटर-प्रोसेस संचार हो सकती है। गैर-संवादात्मक, I/O केवल ईवेंट के लिए, Windows में इनपुट/आउटपुट समापन पोर्ट|I/O पूर्णता पोर्ट हैं। I/O समापन पोर्ट लूप संदेश लूप से अलग से चलते हैं, और बॉक्स के बाहर संदेश लूप से इंटरैक्ट नहीं करते हैं।
अधिकांश Win32 अनुप्रयोग प्रक्रिया सामग्री का दिल WinMain() फ़ंक्शन है, जो us/library/ms644936.aspx GetMessage() लूप में। GetMessage() संदेश या ईवेंट प्राप्त होने तक ब्लॉक करता है (फ़ंक्शन के साथ PeekMessage() एक गैर-अवरुद्ध विकल्प के रूप में)। कुछ वैकल्पिक प्रसंस्करण के बाद, यह DispatchMessage() को कॉल करेगा, जो प्रासंगिक हैंडलर को संदेश भेजता है, जिसे विंडोप्रोक भी कहा जाता है। आम तौर पर, जिन संदेशों में कोई विशेष WindowProc() नहीं होता है, उन्हें WindowProc#Default_processing, डिफ़ॉल्ट रूप से भेजा जाता है। DispatchMessage() संदेश के HWND स्मार्ट सूचक के विंडोप्रोक को कॉल करता है (RegisterClass() फ़ंक्शन के साथ पंजीकृत)।
संदेश आदेश
Microsoft Windows के अधिक हाल के संस्करण प्रोग्रामर को गारंटी देते हैं कि संदेशों को एक एप्लिकेशन के संदेश लूप में वितरित किया जाएगा ताकि वे सिस्टम और उसके बाह्य उपकरणों द्वारा देखे जा सकें। थ्रेड (कंप्यूटिंग) अनुप्रयोगों के डिज़ाइन परिणामों पर विचार करते समय यह गारंटी आवश्यक है।
हालाँकि, कुछ संदेशों के अलग-अलग नियम होते हैं, जैसे संदेश जो हमेशा अंतिम रूप से प्राप्त होते हैं, या भिन्न दस्तावेजी प्राथमिकता वाले संदेश।[4]
एक्स विंडो सिस्टम
एक्सलिब इवेंट लूप
X Window सिस्टम एप्लिकेशन सीधे Xlib का उपयोग कर के चारों ओर बनाया गया है XNextEvent कार्यों का परिवार; XNextEvent ईवेंट क्यू पर कोई ईवेंट दिखाई देने तक ब्लॉक करता है, जिसके बाद एप्लिकेशन इसे उचित रूप से संसाधित करता है। Xlib इवेंट लूप केवल विंडो सिस्टम इवेंट्स को हैंडल करता है; जिन अनुप्रयोगों को अन्य फ़ाइलों और उपकरणों पर प्रतीक्षा करने में सक्षम होने की आवश्यकता होती है, वे आदिम से अपने स्वयं के ईवेंट लूप का निर्माण कर सकते हैं जैसे ConnectionNumber, लेकिन व्यवहार में थ्रेड (कंप्यूटिंग) का उपयोग करते हैं।
बहुत कम प्रोग्राम सीधे Xlib का उपयोग करते हैं। अधिक सामान्य स्थिति में, Xlib पर आधारित GUI टूलकिट आमतौर पर ईवेंट जोड़ने का समर्थन करते हैं। उदाहरण के लिए, एक्स टूलकिट इंट्रिनिक्स पर आधारित टूलकिट है XtAppAddInput() और XtAppAddTimeout().
कृपया ध्यान दें कि सिग्नल हैंडलर से Xlib फ़ंक्शंस को कॉल करना सुरक्षित नहीं है, क्योंकि X एप्लिकेशन मनमाने ढंग से बाधित हो सकता है, उदा। अंदर XNextEvent. X11R5, X11R6 और Xt के समाधान के लिए [1] देखें।
जीएलआईबी इवेंट लूप
GLib इवेंट लूप मूल रूप से GTK में उपयोग के लिए बनाया गया था, लेकिन अब इसका उपयोग गैर-GUI अनुप्रयोगों में भी किया जाता है, जैसे D-Bus । पोल किया गया संसाधन फाइल डिस्क्रिप्टर का संग्रह है जिसमें एप्लिकेशन रुचि रखता है; यदि कोई सिग्नल (कंप्यूटिंग) आता है या टाइमआउट (कंप्यूटिंग) समाप्त हो जाता है (उदाहरण के लिए यदि एप्लिकेशन ने टाइमआउट या निष्क्रिय कार्य निर्दिष्ट किया है) तो पोलिंग ब्लॉक बाधित हो जाएगा। जबकि GLib में फाइल डिस्क्रिप्टर और चाइल्ड टर्मिनेशन इवेंट्स के लिए अंतर्निहित समर्थन है, किसी भी इवेंट के लिए एक इवेंट स्रोत जोड़ना संभव है जिसे तैयार-जांच-प्रेषण मॉडल में संभाला जा सकता है। glib/2.30/glib-The-Main-Event-Loop.html#mainloop-states
GLib ईवेंट लूप पर निर्मित एप्लिकेशन लाइब्रेरी में GStreamer और GnomeVFS की एसिंक्रोनस I/O विधियाँ शामिल हैं, लेकिन GTK सबसे दृश्यमान क्लाइंट लाइब्रेरी बनी हुई है। विंडोिंग सिस्टम (एक्स विंडो सिस्टम में, एक्स यूनिक्स डोमेन सॉकेट से पढ़ा गया) की घटनाओं को जीडीके द्वारा जीटीके घटनाओं में अनुवादित किया जाता है और एप्लिकेशन के विजेट ऑब्जेक्ट्स पर जीएलआईबी सिग्नल के रूप में उत्सर्जित किया जाता है।
macOS कोर फाउंडेशन रन लूप
प्रति थ्रेड ठीक एक CFRunLoop की अनुमति है, और मनमाने ढंग से कई स्रोत और पर्यवेक्षक संलग्न किए जा सकते हैं। स्रोत तब रन लूप के माध्यम से पर्यवेक्षकों के साथ संवाद करते हैं, इसके साथ कतारबद्ध और संदेशों के प्रेषण का आयोजन करते हैं।
CFRunLoop कोकोआ (API) में एक NSRunLoop के रूप में अमूर्त है, जो किसी भी संदेश (गैर-प्रतिबिंब (कंप्यूटर विज्ञान) रनटाइम में फ़ंक्शन कॉल के बराबर) को किसी भी वस्तु को प्रेषण के लिए कतारबद्ध करने की अनुमति देता है।
यह भी देखें
- अतुल्यकालिक I/O
- घटना-संचालित प्रोग्रामिंग
- अंतःप्रक्रम संचार
- संदेश देना
- गेम प्रोग्रामिंग में गेम लूप # गेम संरचना
संदर्भ
- ↑ "Linux_2_6_16 - Linux कर्नेल Newbies". kernelnewbies.org. Retrieved 2021-03-03.
- ↑ D. J. Bernstein. "सेल्फ-पाइप ट्रिक".
- ↑ BUGS, : synchronous I/O multiplexing – Linux Programmer's Manual – System Calls
- ↑ GetMessage() function with message priority list.
