2011-02-12 15 views
5

प्रश्न:gevent का उपयोग करना और एक उपप्रक्रिया के साथ संवाद के लिए एक साथ बहु

मैं एक कुशल तरीके से विंडोज पर एक साथ बहु मॉड्यूल का उपयोग कर सकते हैं gevent साथ?

परिदृश्य:

मैं एक gevent आधारित अजगर विंडोज पर कर अतुल्यकालिक मैं/हे आवेदन किया है। एप्लिकेशन ज्यादातर I/O बाध्य है, लेकिन उच्च CPU लोड की स्पाइक्स भी हैं। इस एप्लिकेशन को अपने stdin और stdout के माध्यम से एक कंसोल अनुप्रयोग को नियंत्रित करने की आवश्यकता होगी। मैं इस कंसोल एप्लिकेशन को संशोधित नहीं कर सकता और उपयोगकर्ता अपने स्वयं के कस्टम एक का उपयोग करने में सक्षम होगा, केवल टेक्स्ट (लाइन) आधारित संचार प्रोटोकॉल तय किया गया है।

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

पहले पढ़ने:

मैं वेब खोज किया गया है एक बहुत और कुछ स्रोत कोड को पढ़ने के लिए है, इसलिए मुझे पता है कि बहु मॉड्यूल एक पाइप विंडोज पर नामित पाइप के आधार पर कार्यान्वयन का उपयोग कर रहा है। Multiprocessing.queue.Queue ऑब्जेक्ट्स की एक जोड़ी दूसरी पायथन प्रक्रिया के साथ संवाद करने के लिए उपयोग की जाएगी। ये कतार उस पाइप कार्यान्वयन पर आधारित हैं, उदा। आईपीसी नामित पाइप के माध्यम से किया जाएगा।

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

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

यदि संभव हो तो कृपया मेरे प्राथमिक उपयोग मामले पर सवाल न करें। धन्यवाद।

+0

मुझे विंडोज और यूनिक्स दोनों पर उपप्रणाली के पाइप को अतुल्यकालिक रूप से पढ़ने और लिखने के लिए उपयुक्त मॉड्यूल मिला। इसे काफी सामान्य समाधान प्राप्त करने के लिए गीवेंट के इवेंट लूप के साथ एकीकृत किया जा सकता है: http://code.activestate.com/recipes/440554- मॉड्यूल-to-allow-asynchronous-subprocess-use-on-win/ – fviktor

उत्तर

1

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

सबसे आसान समाधान आपके कंसोल अनुप्रयोगों को बढ़ाकर और कंसल्टर्स में और बाहर कंसोल से जोड़कर सरल I/O का उपयोग करना होगा। विचार करने के लिए दो प्रमुख कारक हैं:

  • क्लाइंट अनुप्रयोगों को लिखना आपके ग्राहकों के लिए बेहद आसान होगा। उन्हें किसी भी प्रकार के आईपीसी, सॉकेट या अन्य कोड के साथ काम नहीं करना पड़ेगा, जो कि कई लोगों के लिए बहुत मुश्किल हो सकता है। इस दृष्टिकोण के साथ, एप्लिकेशन सिर्फ stdin से पढ़ा जाएगा और stdout लिखना होगा।
  • इस दृष्टिकोण का उपयोग करके कंसोल अनुप्रयोगों का परीक्षण करना बेहद आसान होगा क्योंकि आप उन्हें मैन्युअल रूप से प्रारंभ कर सकते हैं, कंसोल में टेक्स्ट दर्ज कर सकते हैं और परिणाम देख सकते हैं।
  • गीवेंट एसिंक पढ़ने/लिखने के लिए एकदम सही फिट है।

हालांकि, नकारात्मकता यह है कि आपको इस एप्लिकेशन को शुरू करना होगा, इसके साथ समवर्ती संचार के लिए कोई समर्थन नहीं होगा, और नेटवर्क पर संचार के लिए कोई समर्थन नहीं होगा। यहां तक ​​कि good example for starters भी है।

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

यहां तक ​​कि प्रशंसकों का समाधान - ZeroC ICE का उपयोग करें। यह बहुत आधुनिक तकनीक है जो लगभग सहज इंटर-प्रोसेस संचार की इजाजत देती है। यह एक कॉरबा हत्यारा है, जिसका उपयोग करना बहुत आसान है। इसका उपयोग बहुत से लोगों द्वारा किया जाता है, जो इसकी कक्षा और चट्टान स्थिर में सबसे तेज़ साबित हुआ है। इस समाधान की सुंदरता यह है कि आप पाइथन, जावा, सी ++ इत्यादि जैसी कई अलग-अलग भाषाओं में प्रोग्राम को एकीकृत कर सकते हैं लेकिन इस अवधारणा से परिचित होने के लिए आपको अपना कुछ समय चाहिए। यदि आप इस तरह से जाने का फैसला करते हैं, तो बस एक दिन पढ़ने के लिए कठिन दस्तावेज खर्च करें।

उम्मीद है कि यह मदद करता है। सौभाग्य!

+0

उत्तर देने के लिए धन्यवाद विस्तार से। Gevent process.py उदाहरण के साथ समस्या यह है कि यह केवल एक संचार चरण लागू करता है। हम एक ऐसे कर्मचारी का उपयोग कर रहे हैं जो किसी भी समय डेटा भेज सकता है और हम इस दौरान स्टॉप कमांड की तरह कमांड भेज सकते हैं। लेकिन यह उपप्रकार को समाप्त नहीं करेगा, यह प्रयोग योग्य रहना चाहिए। हालांकि, मैं दो लूप को एकीकृत करने की कोशिश करूंगा। यह विंडोज़ पर मदद नहीं कर सकता है, लेकिन कोशिश करने लायक है। टीसीपी/आईपी का उपयोग करना एक और विकल्प है जिसके बारे में मैं सोच रहा था, लेकिन इसे एक रैपर परत की आवश्यकता होगी, जो चीजों को जटिल बनाता है और समाधान को भारी वजन देता है। मैं ज़ीरोसी आईसीई पर एक नज़र डालेगा। – fviktor

+0

@fviktor: आपका स्वागत है। आप किसी भी समय async I/O का उपयोग कर डेटा भेज सकते हैं। आपको केवल गारंटी देने की आवश्यकता होगी कि आप समानांतर में एकाधिक लेखन नहीं करेंगे। समर्पित लेखक धागा और कुछ कतार इस मामले में मदद करता है। –

0

आपका प्रश्न पहले से ही पुराना है। फिर भी, मैं http://gehrcke.de/gipc की सिफारिश करना चाहता हूं - मुझे विश्वास है - एक बहुत ही सीधे फैशन में उल्लिखित चुनौती से निपटने के लिए। असल में, यह आपको अपने एप्लिकेशन (विंडोज़ पर भी) में कहीं भी मल्टीप्रोसेसिंग-आधारित बाल प्रक्रियाओं को एकीकृत करने की अनुमति देता है। Process ऑब्जेक्ट्स (जैसे join() पर कॉल करना) के साथ बातचीत, gevent-cooperative है। अपने पाइप प्रबंधन के माध्यम से, यह सहकारी रूप से इंटर-प्रोसेस संचार को अवरुद्ध करने की अनुमति देता है। हालांकि, विंडोज़ पर, वर्तमान में आईपीसी पॉज़िक्स-अनुपालन प्रणालियों की तुलना में बहुत कम कुशल है (क्योंकि गैर-अवरुद्ध I/O को थ्रेड पूल के माध्यम से अनुकरण किया जाता है)। आपके आवेदन की आईपीसी मैसेजिंग वॉल्यूम के आधार पर, यह महत्व का हो सकता है या नहीं।