चयन / पोल / एपोल: व्यावहारिक अंतर

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

इस लेख में हम विचार करेंगे:

• चयन करें ()
• पोल ()
• एपोल ()
• libevent

चयन () का उपयोग करना

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

चयन () का उपयोग करने के लिए, डेवलपर को वर्णनकर्ता और घटनाओं के साथ कई fd_set संरचनाओं को इनिशियलाइज़ और पॉप्युलेट करने की आवश्यकता होती है जिन्हें मॉनिटर करने की आवश्यकता होती है, और फिर select () कॉल करें। एक विशिष्ट कोड कुछ इस तरह दिखता है:

fd_set fd_in, fd_out; struct timeval tv; //   FD_ZERO( &fd_in ); FD_ZERO( &fd_out ); //        sock1 FD_SET( sock1, &fd_in ); //        sock2 FD_SET( sock2, &fd_out ); //       (select   ) int largest_sock = sock1 > sock2 ? sock1 : sock2; //    10  tv.tv_sec = 10; tv.tv_usec = 0; //  select int ret = select( largest_sock + 1, &fd_in, &fd_out, NULL, &tv ); //    if ( ret == -1 ) //  else if ( ret == 0 ) // ,    else { if ( FD_ISSET( sock1, &fd_in ) ) //    sock1 if ( FD_ISSET( sock2, &fd_out ) ) //    sock2 } 

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

• चयन इसके लिए दिए गए fd_sets संरचनाओं को संशोधित करता है, ताकि उनमें से किसी का भी पुन: उपयोग न किया जा सके। यहां तक ​​कि अगर आपको कुछ भी बदलने की आवश्यकता नहीं है (उदाहरण के लिए, डेटा का एक टुकड़ा प्राप्त करने के बाद, आप अधिक प्राप्त करना चाहते हैं), तो fd_sets संरचनाओं को पुन: स्थापित करना होगा। ठीक है, या FD_COPY का उपयोग करके पहले से सहेजे गए बैकअप से कॉपी करें। और यह प्रत्येक चयन कॉल से पहले बार-बार करना होगा।
• यह जानने के लिए कि किस डिस्क्रिप्टर ने ईवेंट उत्पन्न किया है, आपको उन सभी को FD_ISSET से मैन्युअल रूप से चुनना होगा। जब आप 2000 डिस्क्रिप्टर की निगरानी करते हैं, और घटना केवल उनमें से एक के लिए हुई (जो कि मतलबी कानून के अनुसार, सूची में अंतिम होगी) - आप बहुत सारे प्रोसेसर संसाधनों को बर्बाद कर देंगे।
• क्या मैंने सिर्फ २००० वर्णनकर्ताओं का उल्लेख किया है? मैं इसे लेकर उत्साहित हो गया। चयन उतना समर्थन नहीं करता है। कम से कम, नियमित लिनक्स पर, सामान्य कर्नेल के साथ। एक साथ देखे गए वर्णनकर्ताओं की अधिकतम संख्या निरंतर FD_SETSIZE द्वारा सीमित है, जो लिनक्स में 1024 के लगभग बराबर है। कुछ ऑपरेटिंग सिस्टम आपको sys / select.h हेडर फ़ाइल को शामिल करने से पहले FD_SETSIZE मान को ओवरराइड करके हैक लागू करने की अनुमति देते हैं, लेकिन यह हैक कुछ सामान्य मानक का हिस्सा नहीं है। वही लिनक्स इसे अनदेखा करेगा।
• आप किसी अन्य थ्रेड से अवलोकनीय सेट से वर्णनकर्ताओं के साथ काम नहीं कर सकते। उपरोक्त कोड को निष्पादित करने वाले एक धागे की कल्पना करें। तो यह शुरू हुआ और इसके चयन () में घटनाओं की प्रतीक्षा करता है। अब कल्पना करें कि आपके पास एक और धागा है जो सिस्टम पर समग्र भार की निगरानी करता है, और अब उसने फैसला किया कि sock1 सॉकेट से डेटा बहुत लंबे समय तक नहीं आया है और कनेक्शन को तोड़ने का समय था। चूंकि नए ग्राहकों की सेवा के लिए इस सॉकेट का पुन: उपयोग किया जा सकता है, इसलिए इसे सही ढंग से बंद करना अच्छा होगा। लेकिन पहला सूत्र अभी इस विवरणक को देख रहा है। यदि हम इसे समान रूप से बंद करते हैं तो क्या होगा? ओह, प्रलेखन के पास इस प्रश्न का उत्तर है और आप इसे पसंद नहीं करेंगे: "यदि चयन के साथ मनाया गया हैंडल () किसी अन्य थ्रेड द्वारा बंद किया गया है, तो आपको अपरिभाषित व्यवहार मिलेगा।"
• Sock1 के माध्यम से कुछ डेटा भेजने की कोशिश करते समय भी यही समस्या दिखाई देती है। हम तब तक कुछ नहीं भेजेंगे जब तक कि सिलेक्ट अपना काम पूरा नहीं कर लेता।
• उन घटनाओं का विकल्प जिन्हें हम मॉनिटर कर सकते हैं, काफी सीमित हैं। उदाहरण के लिए, यह निर्धारित करने के लिए कि रिमोट सॉकेट बंद कर दिया गया है, आपको सबसे पहले, उस पर आने वाले डेटा की घटनाओं की निगरानी करनी चाहिए, और दूसरी बात, इस डेटा को पढ़ने की कोशिश करें (बंद सॉकेट के लिए 0 लौटेगा पढ़ें)। सॉकेट से डेटा पढ़ते समय इसे अभी भी स्वीकार्य कहा जा सकता है (0 पढ़ें - सॉकेट बंद है), लेकिन क्या होगा यदि इस समय हमारा वर्तमान कार्य इस सॉकेट को डेटा भेजना है और अब इससे डेटा पढ़ने की आवश्यकता नहीं है?
• चुनिंदा "सबसे बड़ा विवरणक" की गणना करने और एक अलग पैरामीटर के रूप में पारित करने के लिए आप पर एक अनावश्यक बोझ डालता है

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

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

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

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

मतदान के साथ ()

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

मतदान का उपयोग करने के लिए, एक डेवलपर को पर्यवेक्षित विवरणकों और घटनाओं के साथ पोलफेड संरचना के सदस्यों को आरंभीकृत करने की आवश्यकता होती है, और फिर पोल () कहते हैं।
एक विशिष्ट कोड इस तरह दिखता है:

 //   struct pollfd fds[2]; //  sock1      fds[0].fd = sock1; fds[0].events = POLLIN; //   sock2 -  fds[1].fd = sock2; fds[1].events = POLLOUT; //   10  int ret = poll( &fds, 2, 10000 ); //    if ( ret == -1 ) //  else if ( ret == 0 ) // ,    else { //  ,  revents      if ( pfd[0].revents & POLLIN ) pfd[0].revents = 0; //     sock1 if ( pfd[1].revents & POLLOUT ) pfd[1].revents = 0; //     sock2 } 

चुनिंदा विधि की समस्याओं को हल करने के लिए पोल बनाया गया था, आइए देखें कि यह कैसे निकला:

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

हमने पहले ही पोल विधि की कमियों के बारे में बात की थी: यह कुछ प्लेटफार्मों पर उपलब्ध नहीं है, जैसे कि विंडोज एक्सपी। विस्टा के बाद से, यह मौजूद है, लेकिन WSAPoll कहा जाता है। प्रोटोटाइप समान है, इसलिए प्लेटफ़ॉर्म-इंडिपेंडेंट कोड के लिए आप एक ओवरराइड लिख सकते हैं, जैसे:

 #if defined (WIN32) static inline int poll( struct pollfd *pfd, int nfds, int timeout) { return WSAPoll ( pfd, nfds, timeout ); } #endif 

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

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

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

आगे देखते हुए, मैं कहूंगा कि निम्नलिखित मामलों में अधिक आधुनिक युग (नीचे चर्चा की गई) की तुलना में भी मतदान बेहतर है:

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

मतदान के साथ ()

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

एपोल का उपयोग करने के लिए थोड़ी अधिक गहन तैयारी की आवश्यकता होती है। डेवलपर को चाहिए:

• Epoll_create कॉल करके एक epoll डिस्क्रिप्टर बनाएं
• संदर्भों को जोड़ने के लिए आवश्यक घटनाओं और संकेत के साथ epoll_event संरचना को आरम्भ करें। यहां "संदर्भ" कुछ भी हो सकता है, एपोल बस उस मान को लौटाया गया घटनाओं में गुजरता है
• वेधशालाओं की सूची में एक हैंडल जोड़ने के लिए epoll_ctl (... EPOLL_CTL_ADD) को कॉल करें
• घटनाओं के लिए प्रतीक्षा करने के लिए कॉल करें epoll_wait () हम इंगित करते हैं कि हम एक समय में कितनी घटनाओं को प्राप्त करना चाहते हैं, उदाहरण के लिए, 20)। पिछले तरीकों के विपरीत, हम इन घटनाओं को अलग से प्राप्त करते हैं, और इनपुट संरचनाओं के गुणों में नहीं। यदि हम 200 विवरणकों का अवलोकन करते हैं और उनमें से 5 को नया डेटा प्राप्त हुआ है - epoll_wait केवल 5 ईवेंट लौटाएगा। अगर 50 घटनाएँ होती हैं, तो पहले 20 हमारे पास वापस आ जाएँगे, और शेष 30 अगली कॉल के लिए प्रतीक्षा करेंगे, वे खो नहीं जाएंगे
• प्रक्रिया प्राप्त की घटनाओं। यह अपेक्षाकृत त्वरित प्रसंस्करण होगा, क्योंकि हम उन विवरणकर्ताओं को नहीं देखते हैं जहां कुछ भी नहीं हुआ

एक विशिष्ट कोड इस तरह दिखता है:

 //   epoll.       ,      //    (    ,   ),        int pollingfd = epoll_create( 0xCAFE ); if ( pollingfd < 0 ) //  //   epoll_event struct epoll_event ev = { 0 }; //     .    ,   // epoll     . , ,       ev.data.ptr = pConnection1; //    ,     ev.events = EPOLLIN | EPOLLONESHOT; //     .        //      epoll_wait -    if ( epoll_ctl( epollfd, EPOLL_CTL_ADD, pConnection1->getSocket(), &ev ) != 0 ) // report error //       20    struct epoll_event pevents[ 20 ]; //  10  int ready = epoll_wait( pollingfd, pevents, 20, 10000 ); //    if ( ret == -1 ) //  else if ( ret == 0 ) // ,    else { //     for ( int i = 0; i < ret; i++ ) { if ( pevents[i].events & EPOLLIN ) { //        ,   Connection * c = (Connection*) pevents[i].data.ptr; c->handleReadEvent(); } } } 

आइए एपोल के दोषों से शुरू करें - वे कोड से स्पष्ट हैं। इस पद्धति का उपयोग करना अधिक कठिन है, आपको अधिक कोड लिखने की आवश्यकता है, यह अधिक सिस्टम कॉल करता है।

लाभ भी स्पष्ट हैं:

• epoll केवल उन विवरणों की एक सूची देता है जिनके लिए वास्तव में देखी गई घटनाएँ होती हैं। आपको एक की तलाश में हजारों संरचनाओं के माध्यम से देखने की आवश्यकता नहीं है, संभवतः वह है जहां अपेक्षित घटना काम की है।
• आप प्रत्येक देखे गए घटना के साथ कुछ सार्थक संदर्भ जोड़ सकते हैं। ऊपर के उदाहरण में, हमने इसके लिए कनेक्शन वर्ग के एक ऑब्जेक्ट के लिए एक पॉइंटर का उपयोग किया - इससे हमें कनेक्शन की एक सरणी के लिए एक और संभावित खोज मिली।
• आप किसी भी समय सूची से सॉकेट जोड़ या हटा सकते हैं। तुम भी मनाया घटनाओं को संशोधित कर सकते हैं। सब कुछ सही ढंग से काम करेगा, यह आधिकारिक रूप से समर्थित और दस्तावेज है।
• आप epoll_wait का उपयोग करके एक ही कतार से घटनाओं की प्रतीक्षा में कई थ्रेड शुरू कर सकते हैं। कुछ ऐसा जो किसी भी तरह से चयन / सर्वेक्षण के साथ नहीं किया जा सकता है।

लेकिन आपको यह भी याद रखना होगा कि एपोल "ऑल-आउट बेहतर पोल नहीं है।" मतदान की तुलना में इसके नुकसान हैं:

• ईवेंट फ्लैग को बदलना (उदाहरण के लिए, READ से WRITE पर स्विच करना) के लिए अतिरिक्त एपोल_सीटीएल सिस्टम कॉल की आवश्यकता होती है, जबकि पोल के लिए आप सिर्फ बिटमास्क (पूरी तरह से उपयोगकर्ता मोड में) बदलते हैं। पढ़ने से लिखने के लिए 5,000 सॉकेट स्विच करने के लिए एपोल के लिए 5,000 सिस्टम कॉल और संदर्भ स्विच की आवश्यकता होगी, जबकि पोल के लिए यह एक लूप में एक तुच्छ बिट ऑपरेशन होगा।
• प्रत्येक नए कनेक्शन के लिए, आपको कॉल स्वीकार करना होगा () और epoll_ctl () दो सिस्टम कॉल हैं। यदि आप पोल का उपयोग करते हैं, तो केवल एक कॉल होगी। बहुत ही कम जीवनकाल के साथ, यह एक अंतर बना सकता है।
• epoll केवल लिनक्स पर उपलब्ध है। अन्य ऑपरेटिंग सिस्टम में समान तंत्र होते हैं, लेकिन फिर भी पूरी तरह से समान नहीं होते हैं। आप एपोल के साथ कोड नहीं लिख पाएंगे, ताकि यह फ्रीबीएसडी पर निर्माण और काम करता है, उदाहरण के लिए।
• अत्यधिक भरा हुआ समानांतर कोड लिखना कठिन है। कई अनुप्रयोगों को इस तरह के मौलिक दृष्टिकोण की आवश्यकता नहीं होती है, क्योंकि उनके लोड स्तर को सरल तरीकों का उपयोग करके आसानी से संसाधित किया जाता है।

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

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

यदि एक या अधिक आइटम विफल हो जाते हैं, तो पोल या लिबवेंट का उपयोग करने पर विचार करें।

libevent

libevent एक पुस्तकालय है जो इस लेख में सूचीबद्ध मतदान विधियों (साथ ही कुछ अन्य) को एकीकृत एपीआई में लपेटता है। यहाँ लाभ यह है कि एक बार कोड लिखने के बाद, आप इसे विभिन्न ऑपरेटिंग सिस्टम पर बना और चला सकते हैं। फिर भी, यह समझना महत्वपूर्ण है कि कामेच्छा सिर्फ एक आवरण है, जिसके अंदर उपरोक्त सभी तरीके काम करते हैं, अपने सभी फायदे और नुकसान के साथ। libevent 1024 से अधिक सॉकेट्स को सुनने के लिए चयन करने के लिए बाध्य नहीं करेगा, और एपोल अतिरिक्त सिस्टम कॉल के बिना घटनाओं की सूची को संशोधित नहीं करेगा। इसलिए अंतर्निहित तकनीकों को जानना अभी भी महत्वपूर्ण है।

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

दो घटनाओं के संयोजन के समय परिवाद का उपयोग करने पर विचार करें:

• आपने चुनिंदा और मतदान के तरीकों को देखा और उन्होंने निश्चित रूप से आपके लिए काम नहीं किया।
• आपको कई OS का समर्थन करने की आवश्यकता है