2012-07-05 5 views
13

मुझे पता है कि मैं गो में select {} वाक्यविन्यास का उपयोग करके एकाधिक चैनलों पर इंतजार कर सकता हूं, और syscall.Select() या इसी तरह के कार्यों का उपयोग करके एकाधिक फ़ाइल डिस्क्रिप्टरों पर प्रतीक्षा कर सकता हूं। लेकिन क्या दोनों चैनलों को एक बार में इंतजार करना संभव है?क्या गो में एक ही समय में दोनों चैनलों और फाइल डिस्क्रिप्टरों पर प्रतीक्षा करना संभव है?

पृष्ठभूमि के लिए, मैं एक गोरआउटिन चाहता हूं जो एक चैनल पर संदेशों के लिए स्वीकार करता है और उन्हें सॉकेट कनेक्शन (gozmq द्वारा प्रदान किया जाता है) पर आगे बढ़ता है, साथ ही साथ सॉकेट कनेक्शन पर उत्तरों की प्रतीक्षा करता है।

अंतर्निहित लाइब्रेरी की थ्रेड सुरक्षा आवश्यकताओं के कारण, सॉकेट को केवल एक ही समय में एक थ्रेड में एक्सेस किया जा सकता है, इसलिए मैं सोच रहा था कि एक सिंगल गोरौटाइन से इसे संभालने का कोई तरीका है या नहीं।

+0

सिर्फ जिज्ञासा के लिए, यह ऐसी चीज है जो आप अन्य परियोजनाओं में कर सकते हैं जैसे https://github.com/duckie/boson –

उत्तर

10

एक चैनल और फ़ाइल डिस्क्रिप्टर दोनों पर चयन करना संभव नहीं है क्योंकि abstractions विभिन्न स्तरों पर हैं। ऑपरेटिंग सिस्टम द्वारा रन रनटाइम और फाइल डिस्क्रिप्टर द्वारा चैनलों को संभाला जाता है। आपको जो चाहिए वह उनके बीच एक पुल बनाना है और इसे net.Pipe() के साथ किया जा सकता है।

सुंदर ज्यादा आप क्या करने की जरूरत epoll()/select() करने के लिए एक goroutine समर्पित अपने zmq-सॉकेट और एक एकल "जागो" net.Pipe() देखने के लिए है। यह आपका मतदान सर्वर है। एक और goroutine आपके पढ़ने और लिखने के चैनलों पर सुनता है। जब कोई पढ़ा या लिखने वाले चैनल भेजता है, तो दूसरा गोरौटाइन मतदान सर्वर को जागने के लिए पाइप पर भेज देगा।

इस प्रकार मानक पुस्तकालय में नेट पैकेज काम करता है। मैं अत्यधिक प्रेरणा के लिए इसे पढ़ने की सलाह देता हूं (या चोरी ... बीएसडी लाइसेंस बहुत उदार है)।

यहां नेट से मतदान सर्वर का विवरण दिया गया है। यह समझने के लिए आपको कोड को पढ़ने की आवश्यकता हो सकती है कि यह क्या कह रहा है, लेकिन यह अनुभाग fd.go से दिखने के लिए एक अच्छी जगह होना चाहिए।

// A pollServer helps FDs determine when to retry a non-blocking 
// read or write after they get EAGAIN. When an FD needs to wait, 
// send the fd on s.cr (for a read) or s.cw (for a write) to pass the 
// request to the poll server. Then receive on fd.cr/fd.cw. 
// When the pollServer finds that i/o on FD should be possible 
// again, it will send fd on fd.cr/fd.cw to wake any waiting processes. 
// This protocol is implemented as s.WaitRead() and s.WaitWrite(). 
// 
// There is one subtlety: when sending on s.cr/s.cw, the 
// poll server is probably in a system call, waiting for an fd 
// to become ready. It's not looking at the request channels. 
// To resolve this, the poll server waits not just on the FDs it has 
// been given but also its own pipe. After sending on the 
// buffered channel s.cr/s.cw, WaitRead/WaitWrite writes a 
// byte to the pipe, causing the pollServer's poll system call to 
// return. In response to the pipe being readable, the pollServer 
// re-polls its request channels. 
// 
// Note that the ordering is "send request" and then "wake up server". 
// If the operations were reversed, there would be a race: the poll 
// server might wake up and look at the request channel, see that it 
// was empty, and go back to sleep, all before the requester managed 
// to send the request. Because the send must complete before the wakeup, 
// the request channel must be buffered. A buffer of size 1 is sufficient 
// for any request load. If many processes are trying to submit requests, 
// one will succeed, the pollServer will read the request, and then the 
// channel will be empty for the next process's request. A larger buffer 
// might help batch requests. 
// 
// To avoid races in closing, all fd operations are locked and 
// refcounted. when netFD.Close() is called, it calls syscall.Shutdown 
// and sets a closing flag. Only when the last reference is removed 
// will the fd be closed. 

गुड लक पुन: कार्यान्वयन नेट। इन सभी के अंत में अच्छी खबर आपके zmq-socket को थ्रेड सुरक्षित में जायेगी।

+0

ऐसा लगता है जैसे यह काम करेगा: किसी अन्य थ्रेड में 'चयन' या 'पोल' करना ज़ेडक की थ्रेड सुरक्षा आवश्यकताओं के साथ विनाश की संभावना नहीं है, इसलिए इसे एक गोरौटाइन में करना और परिणाम को चैनल के माध्यम से वापस संचार करना अच्छा समाधान। धन्यवाद! –

1

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

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

+0

लाइब्रेरी नेट पर आधारित नहीं है। कॉन। यह विशेष रूप से कहता है कि सॉकेट को कई धागे से समवर्ती रूप से उपयोग नहीं किया जा सकता है: http://api.zeromq.org/2-2:zmq-socket। मैं सॉकेट पर पढ़ने की कोशिश को अवरुद्ध नहीं कर सकता, क्योंकि किसी भी डेटा प्राप्त होने से पहले मुझे सॉकेट में लिखने की आवश्यकता हो सकती है। –

2

प्रत्येक fd के लिए एक नया गोरआउटिन स्पॉन करें, आप प्रतीक्षा करना चाहते हैं, उन्हें fd चैनल पढ़ने के लिए चैनल पर चयन करें, चैनलों पर चयन करें।

+0

आप इन goroutine को रोकने के लिए कैसे कहते हैं? एफडी बंद करना एक विश्वसनीय तरीका नहीं है। – chmike

+0

@chmike अगर दायरस्क्रिप्टर को बंद करना आपके धागे को सूचित नहीं करता है - अपनी ओएस टीम में एक बग फ़ाइल करें। आईओओ, एक एफडी बंद करना एक दस्तावेज, भरोसेमंद तरीका है जिसे इसे अधिसूचित पढ़ने की प्रक्रिया है। –

+0

पढ़ने में अवरुद्ध होने पर थ्रेड/प्रक्रिया अधिसूचित की जाती है। अन्यथा यह नहीं है। अगर एक एफडी बंद है, तो कर्नेल इसका पुन: उपयोग करने के लिए स्वतंत्र है। यदि ऐसा होता है, तो goroutine बंद होने से अवगत नहीं होगा और पुन: उपयोग किए गए एफडी के साथ पहचाने गए किसी अन्य स्रोत से पढ़ना शुरू कर सकता है। इस कारण से एकमात्र विश्वसनीय समाधान एफडी और एक पाइप पर चयन का उपयोग करना है जो अधिसूचना बाइट भेजने के लिए उपयोग किया जाता है। पाठ्यक्रम के – chmike

संबंधित मुद्दे

 संबंधित मुद्दे