मैं select() बनाम poll() के साथ तुलना शुरू करके सुझाव दूंगा। लिनक्स pselect() और ppoll() दोनों प्रदान करता है; और अतिरिक्त const sigset_t *pselect() और ppoll() (बनाम select() और poll()) के लिए तर्क प्रत्येक "पी-संस्करण" पर समान प्रभाव डालता है, जैसा कि यह था। यदि आप सिग्नल का उपयोग नहीं कर रहे हैं, तो आपके पास सुरक्षा के लिए कोई दौड़ नहीं है, इसलिए मूल प्रश्न वास्तव में दक्षता और प्रोग्रामिंग की आसानी के बारे में है।
इस बीच पहले से ही एक stackoverflow.com उत्तर है: what are the differences between poll and select।
दौड़ के लिए: एक बार जब आप सिग्नल (किसी भी कारण से) का उपयोग शुरू करते हैं, तो आप सीखेंगे कि सामान्य रूप से सिग्नल हैंडलर को volatile sig_atomic_t का एक चर सेट करना चाहिए ताकि सिग्नल का पता चला हो। इसके लिए मूल कारण यह है कि कई लाइब्रेरी कॉल re-entrant नहीं हैं, और एक सिग्नल डिलीवर किया जा सकता है, जबकि आप इस तरह के दिनचर्या में "मध्य में" होते हैं। उदाहरण के लिए, बस stdout (सी) या cout (सी ++) जैसे स्ट्रीम-शैली डेटा संरचना में एक संदेश प्रिंट करना पुन: प्रवेश समस्याएं पैदा कर सकता है।
मान लीजिए आप कोड एक volatile sig_atomic_t flag चर का उपयोग करता है, शायद SIGINT, कुछ इस तरह पकड़ने के लिए है (यह भी http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html देखें):
volatile sig_atomic_t got_interrupted = 0;
void caught_signal(int unused) {
got_interrupted = 1;
}
...
struct sigaction sa;
sa.sa_handler = caught_signal;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESTART;
if (sigaction(SIGINT, &sa, NULL) == -1) ... handle error ...
...
अब, अपने कोड के मुख्य शरीर में, आप चाहते हो सकता है करने के लिए "रन बाधित जब तक":
while (!got_interrupted) {
... do some work ...
}
यह ठीक जब तक आप इस तरह के select या 0 के रूप में कॉल है कि कुछ इनपुट/आउटपुट के लिए इंतजार, बनाने के लिए की आवश्यकता होगी, शुरू है। "प्रतीक्षा" कार्रवाई को उस I/O के लिए प्रतीक्षा करने की आवश्यकता है, लेकिन यह भी को SIGINT बाधा के लिए प्रतीक्षा करने की आवश्यकता है। अगर तुम सिर्फ लिखने:
while (!got_interrupted) {
... do some work ...
result = select(...); /* or result = poll(...) */
}
तो यह है कि बाधा नहीं होगा सिर्फ इससे पहले कि आप select() या poll() फोन, बल्कि बाद में की तुलना में संभव है। इस मामले में, आपको बाधा मिली - और परिवर्तनीय got_interrupted सेट हो गया- लेकिन उसके बाद, आप प्रतीक्षा करना शुरू कर देते हैं। प्रतीक्षा करने से पहले आपको got_interrupted वैरिएबल की जांच करनी चाहिए, इसके बाद नहीं।
आप लेखन की कोशिश कर सकते हैं:,
while (!got_interrupted) {
... do some work ...
if (!got_interrupted)
result = select(...); /* or result = poll(...) */
}
यह "रेस खिड़की" सिकुड़ता है क्योंकि अब आप बाधा का पता लगा लेंगे अगर ऐसा होता है, जबकि आप "कुछ काम करना" कोड में हैं; लेकिन अभी भी एक दौड़ है, क्योंकि के बाद बाधा हो सकती है, आप चर का परीक्षण करते हैं, लेकिन चयन-या-पोल से ठीक पहले।
समाधान "परीक्षण, तो इंतजार" बनाने के लिए अनुक्रम "परमाणु", sigprocmask का संकेत-अवरुद्ध गुणों का उपयोग करते है (या, POSIX पिरोया में कोड, pthread_sigmask):
sigset_t mask, omask;
...
while (!got_interrupted) {
... do some work ...
/* begin critical section, test got_interrupted atomically */
sigemptyset(&mask);
sigaddset(&mask, SIGINT);
if (sigprocmask(SIG_BLOCK, &mask, &omask))
... handle error ...
if (got_interrupted) {
sigprocmask(SIG_SETMASK, &omask, NULL); /* restore old signal mask */
break;
}
result = pselect(..., &omask); /* or ppoll() etc */
sigprocmask(SIG_SETMASK, &omask, NULL);
/* end critical section */
}
(ऊपर कोड वास्तव में इतना अच्छा नहीं है, यह दक्षता के बजाय चित्रण के लिए संरचित है - सिग्नल मास्क मैनिपुलेशन को थोड़ा अलग करने के लिए और अधिक कुशल है, और "बाधित हो गया" परीक्षण अलग-अलग रखें)।
जब तक आप वास्तव में, हालांकि, आप केवल select() और poll() तुलना की जरूरत है (और यदि आप वर्णनकर्ता की बड़ी संख्या की आवश्यकता होगी, शुरू करते हैं, epoll() की तरह घटना के आधार पर सामान में से कुछ या तो एक से अधिक कुशल है) SIGINT को पकड़ने के लिए की आवश्यकता होगी,, शुरू करते हैं।
"इसके लिए मूल कारण यह है कि कई लाइब्रेरी कॉल फिर से प्रवेश नहीं कर रहे हैं" तो क्या होता है जब सिग्नल वितरित किया जाता है जबकि हम "पढ़ने" के बीच में होते हैं। क्या इसका मतलब यह है कि हम कभी भी फिर से पढ़ने का उपयोग नहीं कर सकते? – kptlronyttcna
@ kptlronyttcna: नहीं, और फिर भी थोड़ा हां: आप सुरक्षित रूप से कॉल नहीं कर सकते हैं, उदाहरण के लिए, सिग्नल हैंडलर में stdin पर 'fread'। इसका मतलब यह नहीं है कि आप * कभी * कॉल 'फ्रेड' नहीं कर सकते हैं, बस सिग्नल हैंडलर में साझा चर पर ऐसा नहीं कर सकते हैं। लाइब्रेरी, सिस्टम और अन्य विवरणों के मुताबिक, आप सुरक्षित रूप से क्या कर सकते हैं, और आप क्या नहीं कर सकते हैं इसका सटीक विवरण। (एक साइड पॉइंट के रूप में, जब 'रीड' एक सिस्टम कॉल होता है, क्योंकि यह लिनक्स और बीएसडी और मैक पर है, तो इसका सटीक व्यवहार अंतर्निहित फ़ाइल-सिस्टम ऑब्जेक्ट पर निर्भर करता है। "धीमे" डिवाइस EINTR त्रुटियों या छोटे पढ़ने को वापस कर सकते हैं।) – torek