सी त्रुटि प्रबंधन के लिए longjmp/setjmp का उपयोग करने के कुछ "अच्छे" तरीके क्या हैं?

Question

मुझे एक प्रोजेक्ट के लिए सी का उपयोग करना है और मैं त्रुटि प्रबंधन के लिए longjmp/setjmp का उपयोग करने के बारे में सोच रहा हूं क्योंकि मुझे लगता है कि रिटर्न कोड की तुलना में एक केंद्रीय स्थान में त्रुटि को संभालना बहुत आसान होगा। अगर मैं ऐसा करने के बारे में कुछ लीड करता हूं तो मैं सराहना करता हूं।

यदि कोई ऐसी त्रुटि उत्पन्न होती है तो मैं विशेष रूप से संसाधन सफाई के साथ चिंतित हूं।

मैं त्रुटियों को कैसे संभाल सकता हूं जिसके परिणामस्वरूप बहु-थ्रेडेड प्रोग्राम्स का उपयोग किया जाता है?

इससे भी बेहतर, क्या कुछ सी लाइब्रेरी है जो त्रुटि/अपवाद हैंडलिंग के लिए पहले से मौजूद है?

Answer 1

इस उदाहरण/ट्यूटोरियल पर एक नज़र डालें।

यदि आप अपने संसाधन आवंटन प्रणाली को डिज़ाइन करते हैं ताकि आप वास्तव में सटीक रूप से साफ कर सकें, तो यह ठीक है - लेकिन यह डिज़ाइन मुश्किल हो सकता है, और आमतौर पर अधूरा होता है, वास्तव में, मानक पुस्तकालय जो आपका कोड स्वयं का उपयोग करता है उन संसाधनों को आवंटित करें जिन्हें जारी किया जाना चाहिए। इसके लिए असाधारण देखभाल की आवश्यकता होती है, और क्योंकि यह पूरी तरह से विश्वसनीय नहीं है, यह लंबे समय से चलने वाले सिस्टमों के लिए उपयुक्त नहीं है जिन्हें setjmp()/longjmp() कॉल के कई उपयोगों को जीवित रहने की आवश्यकता हो सकती है (वे रिसाव, विस्तार और अंततः कारण समस्या का)।

Answer 2

मुझे केवल एकsetjmp()/longjmp() के लिए उपयोग किया गया है और यह त्रुटि प्रबंधन के साथ नहीं किया गया था।

इसके लिए इसका उपयोग करने की कोई ज़रूरत नहीं है क्योंकि इसे हमेशा पालन करने में आसान कुछ भी किया जा सकता है। setjmp()/longjmp() का उपयोग goto के समान है, जिसमें इसे आसानी से दुरुपयोग किया जा सकता है। कुछ भी जो आपके कोड को कम पठनीय बनाता है सामान्य रूप से एक बुरा विचार है। ध्यान दें कि मैं यह नहीं कह रहा हूं कि वे स्वाभाविक रूप से खराब हैं, सिर्फ वे विकल्प से खराब कोड को आसान बना सकते हैं।

एफडब्ल्यूआईडब्ल्यू, एक स्थान जहां वे अमूल्य थे, वह एक परियोजना थी जो मैंने उद्योग के शुरुआती दिनों में किया था (एमएस-डॉस 6 टाइम फ्रेम)। मैं टर्बो सी का उपयोग कर एक सहकारी बहु-थ्रेडिंग लाइब्रेरी को एक साथ रखने में कामयाब रहा, जो कार्यों को स्विच करने के लिए yield() फ़ंक्शन में उन कार्यों का उपयोग करता था।

मुझे यकीन है कि मैंने उन दिनों से उन्हें छुआ नहीं है (या इसकी आवश्यकता थी)।

Answer 3

सिम्बियन ने तंत्र को longjmp() के संदर्भ में कार्यान्वित किया है और यह उन सभी चीजों के माध्यम से अच्छी तरह से चलने के रूप में कार्य करता है जो आपको करने की ज़रूरत है।

सिम्बियन का वैश्विक 'क्लीनअप स्टैक' है जिसे आप साफ़ करना चाहते हैं, जिसे आप साफ करना चाहते हैं, एक कूद होना चाहिए। स्वचालित स्टैक के मैन्युअल विकल्प यह अनचाहे है कि एक C++ कंपाइलर करता है जब एक C++ अपवाद फेंक दिया जाता है।

सिम्बियन में 'जाल harnesses' था कि यह बाहर कूद जाएगा; इन्हें घोंसला जा सकता है।

(सिम्बियन ने हाल ही में सी ++ अपवादों के संदर्भ में इसे फिर से कार्यान्वित किया है, लेकिन इंटरफेस अपरिवर्तित बनी हुई है)।

सभी एक साथ, मुझे लगता है कि उचित सी ++ अपवाद कोडिंग त्रुटियों से कम प्रवण होते हैं और आपके स्वयं के सी समकक्ष रोलिंग से बहुत तेज़ होते हैं।

(आधुनिक सी ++ कंपाइलर्स 'शून्य ओवरहेड' अपवादों पर बहुत अच्छे होते हैं, जब उन्हें फेंक दिया नहीं जाता है, उदाहरण के लिए; longjmp() को सभी रजिस्टरों की स्थिति को स्टोर करना होता है और यहां तक ​​कि जब कूद को बाद में नहीं लिया जाता है, तो मूल रूप से कभी भी अपवादों के जितना तेज़ न हो।)

सी ++ को बेहतर सी के रूप में उपयोग करते हुए, जहां आप केवल अपवाद और आरएआईआई अपनाते हैं, अपवाद अनुकरण के लिए longjmp() का उपयोग करना एक अच्छा मार्ग होगा।

Answer 4

अपवाद बहुत बेहतर सामान्य तंत्र हैं, लेकिन सी अतीत के गहरे अंधेरे दिनों में, मैंने एक प्रोसेसर एमुलेटर लिखा जिसमें एक कमांड खोल शामिल था। शेल हैंडलिंग के लिए setjmp/longjmp के लिए इस्तेमाल किया जाने वाला खोल (यानी, प्रोसेसर चल रहा है और उपयोगकर्ता ब्रेक/ctrl-c हिट करता है, कोड एसआईजीआईएनटी और लंबे समय तक शेल पर लम्बा हुआ है)।आप संसाधन सफाई के बारे में चिंतित हैं, तो आप गंभीरता से सोचने लगा कि क्या longjmp() और setjmp() एक अच्छा विचार हैं
http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

Answer 5

:

Answer 6

मैंने setjmp/longjmp का उपयोग किया है, कॉलबैक के भीतर से बचने के लिए, अन्य पुस्तकालय स्तरों के माध्यम से मेरे रास्ते पर बातचीत किए बिना।

वह मामला (यदि मुझे सही याद है) वह जगह थी जहां एक yacc- जेनरेटेड पार्सर के भीतर एक कोड एक (गैर-वाक्य रचनात्मक) समस्या का पता लगा सकता था, और पार्स को त्यागना चाहता था लेकिन कॉलर को एक उचित उपयोगी त्रुटि रिपोर्ट देता था सभी yacc- जेनरेट कोड के दूसरी तरफ। एक और उदाहरण एक एक्सपैट पार्सर से बुलाए गए कॉलबैक के भीतर था। प्रत्येक मामले में, ऐसा करने के अन्य तरीके थे, लेकिन वे इस तरह से बाहर निकलने की तुलना में अधिक बोझिल और अस्पष्ट लगते थे।

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

बहु-थ्रेडेड प्रोग्रामिंग के संदर्भ में इसे करना? मुझे यकीन है कि यह असंभव नहीं है, लेकिन ओहः अब अपने एस्पिरिन के परिवार-पैक को बाहर निकालें। setjmp/longjmp जोड़ों को जितना संभव हो उतना करीब रखना संभव है। जब तक एक मिलान setjmp/longjmp जोड़ी एक ही धागे के भीतर है, मुझे उम्मीद है कि आप ठीक रहेगा, लेकिन ... वहां सावधान रहें।