मैक ओएस एक्स: क्या प्रक्रिया के "मुख्य थ्रेड" बनने के लिए गैर-मुख्य धागे को असंभव करना संभव है?

Question

मैक ओएस एक्स (10.6.7) के तहत मुझे एक जीयूआई/थ्रेडिंग से संबंधित समस्या है। मैं wxwidgets ढांचे का उपयोग कर रहा हूं (ver 2.9.1), और यह मेरे मामले में कोको पर रहता है। आवेदन डिजाइन इस तरह है:

• धागा # 1 (यानी "मुख्य थ्रेड"): मुख्य प्रवेश करती है(), स्विच को पार्स करता है, और यदि आवश्यक हो, एक और धागा (इसे POSIX पुरातन का प्रयोग करके) की शुरूआत।
• थ्रेड # 2 (ए.के.ए. "जीयूआई थ्रेड"): WxWidgets को प्रारंभ करने और जीयूआई दिखाने के लिए wxEntry का उपयोग करता है।

अधिकांश अन्य जीयूआई ढांचे की तरह, कोको थ्रेड-सुरक्षित नहीं है, इसलिए हम सभी जीयूआई कॉल थ्रेड # 2 के भीतर से सुनिश्चित करते हैं, यदि आवश्यक हो तो संदेश पास कर लें। फिर भी, उस विशेष मामले में, शुरुआतीकरण के दौरान कोको के आंतरिक इलाकों में एनएसयूंडो मैनेजर से अधिक सटीक होने के लिए दावा किया जाता है कि "मुख्य धागे के बाहर मुझे उपयोग करना सुरक्षित नहीं है"। भले ही थ्रेड # 2 मुख्य धागा जहां तक ​​कुछ भी GUI- संबंधित है।

ठीक है, NSUndoManager को मुख्य धागे से बाहर निकलने का पता लगाने का एक तरीका होना चाहिए (शायद एनएसटीएचड :: isMainThread() का उपयोग कर)। तो मेरा सवाल यह है: क्या इस बारे में NSUndoManager (और कोको सामान्य रूप से) करना संभव है? और इससे भी बेहतर, धागा # 2 "मुख्य थ्रेड" घोषित करने के लिए, धागा # 1 द्वितीयक बनने के साथ? असल में, मुझे एक एपीआई कॉल की आवश्यकता है जैसे "कॉलिंग थ्रेड मुख्य वन बनें"। अनियंत्रित जादूगर और उद्देश्य सी ++ ठीक है, जब तक यह ओएस एक्स 10.5 पर भी काम करता है।

पीपी। कोड, जैसा कि अब है, विंडोज/लिनक्स/मैकोज़क्स + कार्बन के तहत बेकार ढंग से काम करता है। इसके अलावा, थ्रेड संरचना को बदलने के लिए इसे फिर से डिजाइन करना एक बड़ा दर्द होगा।

Answer 1

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