इवेंट लूप

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

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

जब इवेंट लूप प्रोग्राम के केंद्रीय नियंत्रण प्रवाह का निर्माण करता है, अधिकांशतः इसे मेन लूप या मेन इवेंट लूप कहा जा सकता है। यह शीर्षक उपयुक्त है, क्योंकि इस प्रकार का इवेंट लूप कार्यक्रम के भीतर उच्चतम स्तर पर नियंत्रण रखता है।

संदेश गुजर रहा है
संदेश पंप को प्रोग्राम की संदेश कतार से संदेशों को 'पंप' करने के लिए कहा जाता है (असाइन किए गए और सामान्यतः अंतर्निहित ऑपरेटिंग सिस्टम के स्वामित्व वाले) प्रसंस्करण के लिए कार्यक्रम में। इसके अन्य अर्थों में, इवेंट लूप अंतर-प्रक्रिया संचार को लागू करने की विधियों में से है। वास्तव में, कई प्रणालियों में संदेश प्रसंस्करण सम्मलित है, जिसमें मच कर्नेल का कर्नेल (कंप्यूटर विज्ञान) या कर्नेल-स्तर घटक सम्मलित है। इवेंट लूप सिस्टम की विशिष्ट कार्यान्वयन तकनीक है जो संदेश देना का उपयोग करती है।

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

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

function main initialize while message != quit message := get_next_message process_message(message) end while

end function

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

उदाहरण के लिए, प्रोग्राम पर विचार करें जो निरंतर अद्यतन फ़ाइल से पढ़ता है और एक्स विंडो सिस्टम में इसकी सामग्री प्रदर्शित करता है, जो क्लाइंट के साथ सॉकेट (या तो यूनिक्स डोमेन सॉकेट या बर्कले सॉकेट ) पर संचार करता है def main:

file_fd = open("logfile.log") x_fd = open_display construct_interface while True: rlist, _, _ = select.select([file_fd, x_fd], [], []): if file_fd in rlist: data = file_fd.read append_to_display(data) send_repaint_message if x_fd in rlist: process_x_messages

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

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

पासिक्स द्वारा निकाला गया समाधान है  कॉल, जो समान है   लेकिन अतिरिक्त लेता है   पैरामीटर, जो सिग्नल मास्क का वर्णन करता है। यह एप्लिकेशन को मुख्य कार्य में सिग्नल को मास्क करने की अनुमति देता है, फिर की अवधि के लिए मास्क को हटा दें   कॉल ऐसे करें कि सिग्नल हैंडलर को केवल तभी बुलाया जाए जब एप्लिकेशन I/O बाध्य हो। चूंकि, का कार्यान्वयन   हमेशा विश्वसनीय नहीं रहे हैं; 2.6.16 से पहले के लाइनेक्स के संस्करणों में a नहीं है   सिस्टम कॉल, glibc को ही दौड़ की स्थिति के लिए प्रवण विधि के माध्यम से इसका अनुकरण करने के लिए मजबूर करना   बचने का है।

एक वैकल्पिक, अधिक पोर्टेबल समाधान, अतुल्यकालिक घटनाओं को स्व-पाइप चाल का उपयोग करके फ़ाइल-आधारित घटनाओं में परिवर्तित करना है, जहां सिग्नल हैंडलर पाइप को बाइट लिखता है जिसके दूसरे सिरे की जाँच की जाती है  मुख्य कार्यक्रम में। लिनक्स कर्नेल संस्करण 2.6.22 में, नया सिस्टम कॉल   जोड़ा गया, जो विशेष फाइल डिस्क्रिप्टर के माध्यम से सिग्नल प्राप्त करने की अनुमति देता है।

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

अधिकांश Win32 अनुप्रयोग प्रक्रिया सामग्री का दिल WinMain फ़ंक्शन है, जो us/library/ms644936.aspx GetMessage लूप में। GetMessage संदेश या ईवेंट प्राप्त होने तक ब्लॉक करता है (फ़ंक्शन के साथ PeekMessage गैर-अवरुद्ध विकल्प के रूप में)। कुछ वैकल्पिक प्रसंस्करण के बाद, यह DispatchMessage को कॉल करेगा, जो प्रासंगिक हैंडलर को संदेश भेजता है, जिसे विंडोप्रोक भी कहा जाता है। सामान्यतः, जिन संदेशों में कोई विशेष WindowProc नहीं होता है, उन्हें WindowProc Default_processing, डिफ़ॉल्ट रूप से भेजा जाता है। DispatchMessage संदेश के एचडब्ल्यूएनडी स्मार्ट सूचक के विंडोप्रोक को कॉल करता है (RegisterClass फ़ंक्शन के साथ पंजीकृत)।

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

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

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

कृपया ध्यान दें कि सिग्नल हैंडलर से Xlib फ़ंक्शंस को कॉल करना सुरक्षित नहीं है, क्योंकि X एप्लिकेशन मनमाने ढंग से बाधित हो सकता है, उदा। अंदर. X11R5, X11R6 और Xt के समाधान के लिए देखें।

जीएलआईबी इवेंट लूप
जी लाइब्रेरी इवेंट लूप मूल रूप से जीटीके में उपयोग के लिए बनाया गया था, लेकिन अब इसका उपयोग गैर-जीयूआई अनुप्रयोगों में भी किया जाता है, जैसे डी-बस । पोल किया गया संसाधन फाइल डिस्क्रिप्टर का संग्रह है जिसमें एप्लिकेशन रुचि रखता है; यदि कोई सिग्नल (कंप्यूटिंग) आता है या टाइमआउट (कंप्यूटिंग) समाप्त हो जाता है (उदाहरण के लिए यदि एप्लिकेशन ने टाइमआउट या निष्क्रिय कार्य निर्दिष्ट किया है) तो पोलिंग ब्लॉक बाधित हो जाएगा। जबकि जी लाइब्रेरी में फाइल डिस्क्रिप्टर और चाइल्ड टर्मिनेशन इवेंट्स के लिए अंतर्निहित समर्थन है, किसी भी इवेंट के लिए इवेंट स्रोत जोड़ना संभव है जिसे तैयार-जांच-प्रेषण मॉडल में संभाला जा सकता है। glib/2.30/glib-The-Main-Event-Loop.html#mainloop-states

जी लाइब्रेरी ईवेंट लूप पर निर्मित एप्लिकेशन लाइब्रेरी में जी स्ट्रीमर और जीनोम वीएफएस की एसिंक्रोनस I/O विधियाँ सम्मलित हैं, लेकिन जीटीके सबसे दृश्यमान क्लाइंट लाइब्रेरी बनी हुई है। विंडोिंग सिस्टम (एक्स विंडो सिस्टम में, एक्स यूनिक्स डोमेन सॉकेट से पढ़ा गया) की घटनाओं को जीडीके द्वारा जीटीके घटनाओं में अनुवादित किया जाता है और एप्लिकेशन के विजेट ऑब्जेक्ट्स पर जीएलआईबी सिग्नल के रूप में उत्सर्जित किया जाता है।

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

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

यह भी देखें

 * अतुल्यकालिक I/O
 * घटना-संचालित प्रोग्रामिंग
 * अंतःप्रक्रम संचार
 * संदेश देना
 * गेम प्रोग्रामिंग में गेम लूप # गेम संरचना

बाहरी कड़ियाँ

 * Meandering Through the Maze of MFC Message and Command Routing
 * Using Messages and Message Queues (MSDN)
 * Using Window Procedures (MSDN)
 * WindowProc (MSDN)