जो कोई भी आईएसओ/आईईसी एससी 22 पर बैठता है, जिसमें डब्लूजी 14 (सी), डब्लूजी 15 (पीओएसईक्स) और डब्लूजी 21 (सी ++) शामिल है, मैं आपको बता सकता हूं कि त्वरित उत्तर नहीं है, सी ++ अपवाद और थ्रेड रद्दीकरण नहीं जा रहा है जल्द ही किसी और को देखें। सी 11 और सी ++ 11 थ्रेड रद्दीकरण का कोई जिक्र नहीं करते हैं, और अगर अगले दस वर्षों के समय में अगले प्रमुख मानकों को रिलीज करने से पहले इसे पहचानने की संभावना नहीं है।
लंबे समय तक उत्तर मानता है कि मानक कैसे काम करते हैं। असल में आईएसओ केवल मानकीकृत कर सकता है कि हर कोई किस पर सहमत हो सकता है, और जब थ्रेड रद्दीकरण की बात आती है तो लोग सहमत नहीं होते हैं। प्रत्येक रद्द करने योग्य सिस्टम कॉल से पहले राज्य को डंप करने के निष्पादन के धागे का पूरा विचार आधुनिक सॉफ्टवेयर विकास के पूरे सिद्धांतों के खिलाफ चला जाता है। यह संकलक अनुकूलन के लिए अत्यधिक समस्याएं पैदा करता है क्योंकि सी ++ अपवाद फेंकने के विपरीत, थ्रेड रद्द करने के लिए थ्रेड_टरमिनेट (स्वयं) को कॉल करने के समान परिभाषित किया जाता है जो स्पष्ट रूप से कुछ भी अतिरिक्त करने से रोकता है (और यहां तक कि रद्दीकरण हैंडलर को कई कार्यान्वयन पर विश्वसनीय रूप से नहीं कहा जाता है), और मुझे नहीं लगता कि थ्रेड रद्दीकरण समर्थक असहमत होंगे कि यह एक खराब समाधान है।
समस्या यह है कि POSIX i/O API को एसिंक पूर्णता संस्करणों के साथ पुन: जारी करने का एकमात्र उचित विकल्प है। और इसके साथ समस्या यह है कि विभिन्न POSIX कार्यान्वयन एसिंक पूर्ण होने के बारे में सोचते हैं। मेरा मतलब है, हम कर्नेल प्रतीक्षा कतारों के लिए मानक पर भी सहमत नहीं हो सकते हैं, इसलिए जब तक इसे एसिंक I/O एपीआई हासिल नहीं किया जा सकता है, तो यह एक लंबा रास्ता है। मेरे पास अगले मानक टीसी/टीआर के लिए कर्नल प्रतीक्षा कतारों पर कुछ आंदोलन करने का प्रस्ताव है, लेकिन प्रस्तावित वस्तु जानबूझकर बेहद सरल है।
हमने सी 11/सी ++ 11 में जो करने की कोशिश की है वह थ्रेडिंग एपीआई के लिए हमेशा गैर-अवरुद्ध संस्करणों के लिए है - वहां केवल एक एपीआई है जिसे गैर-अवरुद्ध नहीं किया जा सकता है जो thread_join है() (कोई thread_timedjoin() नहीं है) और मैं ऑस्टिन वर्किंग ग्रुप अनुमोदन के बाद व्यक्तिगत रूप से एक इरेटा जमा करने की योजना बना रहा हूं। अन्य सभी मामलों में, कोई हमेशा ऐसा कुछ निर्माण कर सकता है जो चुनाव सक्षम नहीं है, लेकिन कार्यक्रम सही है।
लंबे समय तक, व्यक्तिगत रूप से बोलते हुए मुझे सी ++ में समान अर्थशास्त्र के बाद सी को अपवाद हैंडलिंग जोड़ने का बहुत अच्छा कारण दिखाई देता है। आपके पास जरूरी ऑब्जेक्ट समर्थन नहीं होगा (मैं वास्तव में गैर-वर्चुअल ऑब्जेक्ट्स को सी को व्यक्तिगत रूप से जोड़ने का समर्थन करता हूं), लेकिन आपके पास स्टैक अवांछित लैम्ब्डा फ़ंक्शन कॉल की अवधारणा होगी। इससे हमें हैक को औपचारिक रूप से परिभाषित तंत्र के साथ थ्रेड रद्दीकरण की औपचारिकता प्रदान करने देगी। यह लिखने की गलती सहिष्णु सी भी आपको हवा लिखने के रूप में अवांछित लिखने से अधिक आसान और सुरक्षित बनाता है, और पुराने सी पारदर्शी रूप से नए सी
अपवाद हैंडलिंग के भीतर अपवाद फेंकने के संबंध में, मुझे व्यक्तिगत रूप से लगता है कि हम हमेशा ऑटो invoking समाप्त() से बेहतर कुछ करने की जरूरत है।चूंकि अवांछित नई वस्तुओं के निर्माण का कारण बन सकता है, या वास्तव में अपवाद का कोई अन्य स्रोत फेंकता है, इसलिए प्रक्रिया को समाप्त करने से पहले पूरे स्टैक को खोलने के लिए हर उचित प्रयास किए जाने पर मैं व्यक्तिगत रूप से बहुत पसंद करूंगा।
तो, संक्षेप में, उम्मीद है कि पीओएसईक्स थ्रेड रद्दीकरण को अनिर्धारित के रूप में देखा जाना जारी रहेगा, और मजबूत संभावना लंबे समय तक चल रही है, इसे कुछ बेहतर तरीके से वंचित कर दिया जाएगा।
बीटीडब्लू, आम तौर पर पीओएसईक्स थ्रेड रद्दीकरण कार्यान्वयन के बीच अत्यधिक अप्राप्य है, इसलिए पॉसिक्स थ्रेड रद्दीकरण का उपयोग करने वाला कोई भी कोड प्रभावी रूप से प्लेटफ़ॉर्म-विशिष्ट व्यवहार पर निर्भर करता है जो गैर-पॉज़िक्स एपीआई का उपयोग करने के समान होता है। यदि आप चाहते हैं कि आपका कोड पोर्टेबल हो, तो POSIX थ्रेड रद्दीकरण का उपयोग न करें। इसके बजाय एक जादू सहित "() या मतदान() का चयन करें" कृपया अब थ्रेड रोकें "फ़ाइल डिस्क्रिप्टर। अपने स्वयं के सी ++ कोड में, मेरे पास वास्तव में एक सिस्टम एपीआई रैपर मैक्रो है जो इस जादू फ़ाइल डिस्क्रिप्टर के लिए परीक्षण करता है और एक विशेष सी ++ अपवाद फेंकता है। यह विंडोज सहित सभी प्लेटफार्मों पर समान व्यवहार सुनिश्चित करता है।
मुझे लगता है कि आपको सी ++ 11 में '' का उपयोग करना चाहिए और पॉज़िक्स नहीं है ... तो आपके पास अपवाद पॉइंटर्स और अपवाद प्रसार पर हैंडल प्राप्त करने के लिए सभी हैं। –
क्या 'पॉज़िक्स थ्रेड रद्दीकरण के लिए एनालॉग है? ऐसा लगता है कि यह निर्दिष्ट करना मुश्किल होगा क्योंकि POSIX थ्रेड रद्दीकरण के पूरे बिंदु यह है कि यह POSIX फ़ंक्शंस के साथ कैसे इंटरैक्ट करता है जो थ्रेड की अगली या असीमित मात्रा के लिए प्रगति को अवरुद्ध कर सकता है। –
अच्छा सवाल; रद्दीकरण के मानक में कुछ भी नहीं है, और इस प्रकार मैं मानता हूं कि पॉज़िक्स धागे के साथ बातचीत के लिए कोई मानक तंत्र नहीं है। क्या आपको रद्दीकरण की आवश्यकता है, यद्यपि? यदि आप सी ++ में अपने समाधान पर पुनर्विचार करते हैं, तो क्या कोई और मूर्खतापूर्ण तरीका नहीं है? –