लिनक्स

Question

में समानांतर प्रसंस्करण मुझे यकीन नहीं है कि मैं जो प्रोग्राम लिख रहा हूं, उसमें एसिंक्रोनस कार्यों को संभालने के बारे में कैसे जाना है और मुझे उम्मीद है कि कोई और अनुभवी मुझे कम से कम सही दिशा में इंगित कर सकता है।

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

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

इसके अतिरिक्त, मैं पहले से ही किसी भी क्रॉस संकलन समस्याओं से बचने के लिए बड़े माध्यमिक पुस्तकालयों से दूर रहना चाहता हूं। किसी सुझाव के लिए अग्रिम धन्यवाद।

Answer 1

स्टीव के उत्तर की मूल विधि लें लेकिन इनिट (8) और नामित पाइप को छोड़ दें।

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

बेशक, अगर कैमरा कोड के साथ वास्तव में समस्याएं हैं तो आपने वास्तव में पूरा किया है, पूरे कार्यक्रम को न छोड़कर विफलताओं को कुछ और अधिक प्रबंधनीय बना दिया गया है। आदर्श रूप से आपको कैमरे कोड को बिना किसी काम के मिलना चाहिए यदि वह आपकी शक्ति के भीतर है।

Answer 2

आपकी समस्या कई प्रक्रियाओं के लिए क्लासिक केस की तरह लगती है, जो किसी प्रकार के इंटर-प्रोसेस संचार (आईपीसी) से संचार करती है।

कैमरे की अपनी प्रक्रिया होनी चाहिए, और यदि वह प्रक्रिया मर जाती है, तो मुख्य प्रक्रिया में कोई समस्या नहीं होनी चाहिए। आप init(8) प्रक्रिया भी कैमरा प्रक्रिया का प्रबंधन कर सकते हैं; जो किसी भी कारण से मरने पर प्रक्रिया को स्वचालित रूप से पुनरारंभ कर सकता है।

आप एक नामित पाइप स्थायी रूप से सेट अप कर सकते हैं, और फिर विफलता के बाद इसे फिर से चालू करने पर कैमरा प्रक्रिया इसे फिर से खोल सकती है।

http://en.wikipedia.org/wiki/Named_pipe

मैं StackOverflow खोज की है और नामित पाइप बनाम की चर्चा पाया:

http://www.tldp.org/LDP/lpg/node15.html

मैं विकिपीडिया पृष्ठ से इस पाया:

यहाँ नामित पाइप के बारे में कुछ प्रलेखन है सॉकेट:

IPC performance: Named Pipe vs Socket

Answer 3

मैंने धागे की कोशिश की है, लेकिन कैमरा थ्रेड में कोई भी समस्या पूरी प्रक्रिया को मारने लगती है।

जब आप पूरी प्रक्रिया को मारते हैं, वास्तव में क्या होता है?

मैंने आपको यह बताया कि आप उपरोक्त समस्या को डीबग करने से बेहतर हैं, बग को एक फोर्क प्रक्रिया में दूर लपेटने की कोशिश करने से बेहतर हैं। एक अविश्वसनीय कैमरे के साथ एक विश्वसनीय कोर सिस्टम की तुलना में, आपके पास एक विश्वसनीय कैमरा सहित एक विश्वसनीय प्रणाली होगी।