गैर-अवरुद्ध सॉकेट पर चयन(), recv() और EWOULDBLOCK

Question

मैं जानना चाहता हूं कि निम्न परिदृश्य वास्तविक है या नहीं ?!

1. का चयन करें() (आरडी) पर गैर अवरुद्ध TCP सॉकेट का कहना है कि सॉकेट तैयार है
2. recv() EWOULDBLOCK वापसी होगी कॉल के बावजूद चयन करने के लिए()

Answer 1

मैं एक लोकप्रिय डेस्कटॉप ऑपरेटिंग जहां O_NONBLOCK TCP सॉकेट, विशेष रूप से लूपबैक इंटरफेस पर चल रहे उन, कभी कभी से recv() के बाद select() रिपोर्ट सॉकेट पढ़ने के लिए तैयार है EAGAIN लौट सकते हैं में किसी त्रुटि के बारे में पता कर रहा हूँ। मेरे मामले में, दूसरी तरफ भेजने के बाद यह भेजता है।

अधिक जानकारी के लिए, मेरे ओकैमल नेटवर्क एप्लिकेशन पर्यावरण वितरण की एनएक्स लाइब्रेरी में t_nx.ml के लिए स्रोत कोड देखें। (link)

Answer 2

यह संभव है के बाद, लेकिन केवल एक परिस्थिति में जहां आपके पास एक ही सॉकेट से पढ़ने की कोशिश कर रहे कई धागे/प्रक्रियाएं हैं।

Answer 3

recv() के लिए आपको EWOULDBLOCK के बजाय EAGAIN मिलेगा, और हाँ यह संभव है। जब से तुम सिर्फ तब select() साथ जाँच की है दो चीजों में से एक हुआ:

• कुछ और (एक और धागा) select() और recv() के बीच इनपुट बफर सूखा गया है।
• एक प्राप्त समय सॉकेट पर सेट किया गया था और यह डेटा प्राप्त किए बिना समाप्त हो गया था।

Answer 4

यह एक बहुप्रचारित वातावरण में संभव है जहां सॉकेट से दो धागे पढ़ रहे हैं। क्या यह एक बहुप्रचारित अनुप्रयोग है?

Answer 5

यदि आप इस सॉकेट पर चयन() और recv() के बीच कोई अन्य सिस्कल नहीं कॉल करते हैं, तो recv() कभी भी EAGAIN या EWOULDBLOCK वापस नहीं आएगा।

मुझे नहीं पता कि आरईवी-टाइमआउट के साथ उनका क्या मतलब है, हालांकि, पॉज़िक्स मानक इसका उल्लेख नहीं करता है ताकि आप सुरक्षित कॉलिंग आरईवी() हो सकें।

Answer 6

हालांकि मेरा आवेदन एक एकल थ्रेडेड है, मैंने देखा कि वर्णित व्यवहार RHEL5 में असामान्य नहीं है। टीसीपी और यूडीपी सॉकेट दोनों जो O_NONBLOCK पर सेट किए गए थे (सेट किया गया एकमात्र सॉकेट विकल्प)। चयन करें() रिपोर्ट करता है कि सॉकेट तैयार है लेकिन निम्नलिखित recv() EAGAIN लौटाता है।

Answer 7

लिनक्स पर यह भी दस्तावेज है कि ऐसा हो सकता है, जैसा कि मैंने इसे पढ़ा है।

Spurious readiness notification for Select System call