नमस्कार, हेब्र! मैं आपके लिए मैट क्लेन द्वारा "एनोवॉय थ्रेडिंग मॉडल" लेख का अनुवाद प्रस्तुत करता हूं।

यह लेख मुझे काफी रोचक लगा और चूँकि Envoy को अक्सर "istio" के भाग के रूप में या "ingress कंट्रोलर" kubernetes के रूप में उपयोग किया जाता है, इसलिए अधिकांश लोगों के पास इसके समान पारस्परिक संपर्क नहीं होता है, उदाहरण के लिए जैसे कि ठेठ कुंवारी या Haproxy स्थापनाओं के साथ। हालांकि, अगर कुछ टूटता है, तो यह समझना अच्छा होगा कि यह अंदर से कैसे काम करता है। मैंने विशेष शब्दों सहित रूसी में यथासंभव पाठ का अनुवाद करने की कोशिश की, जो लोग इसे देखने के लिए दर्दनाक हैं, मैंने मूल कोष्ठक में छोड़ दिया। बिल्ली में आपका स्वागत है।

Envoy कोड बेस पर निम्न-स्तरीय तकनीकी प्रलेखन वर्तमान में बहुत दुर्लभ है। इसे ठीक करने के लिए, मैं विभिन्न दूत उप-प्रणालियों के बारे में ब्लॉग लेखों की एक श्रृंखला बनाने की योजना बना रहा हूं। चूंकि यह पहला लेख है, कृपया मुझे बताएं कि आप क्या सोचते हैं और आपको निम्नलिखित लेखों में क्या दिलचस्पी हो सकती है।

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

थ्रेडिंग ओवरव्यू

दूत तीन अलग-अलग प्रकार की धाराओं का उपयोग करता है:

मुख्य: यह धागा प्रक्रिया की शुरुआत और अंत को नियंत्रित करता है, DNS, स्वास्थ्य जाँच, सामान्य क्लस्टर और सेवा प्रबंधन (रनटाइम), सांख्यिकी रीसेट, प्रशासन और सामान्य प्रबंधन सहित एक्सडीएस (xDiscovery सेवा) एपीआई के सभी प्रसंस्करण। प्रक्रियाओं - लिनक्स सिग्नल, हॉट रिस्टार्ट, आदि। इस धागे में जो कुछ भी होता है वह अतुल्यकालिक और गैर-अवरुद्ध है। सामान्य तौर पर, मुख्य धागा कार्यक्षमता की सभी महत्वपूर्ण प्रक्रियाओं का समन्वय करता है, जिसे पूरा करने के लिए बड़ी संख्या में सीपीयू की आवश्यकता नहीं होती है। यह अधिकांश नियंत्रण कोड को लिखने की अनुमति देता है जैसे कि यह एकल-थ्रेडेड था।
कार्यकर्ता: डिफ़ॉल्ट रूप से, Envoy सिस्टम में प्रत्येक हार्डवेयर थ्रेड के लिए एक वर्कर थ्रेड बनाता है, इसे --concurrency विकल्प का उपयोग करके नियंत्रित किया जा सकता है। प्रत्येक कार्यकर्ता थ्रेड एक "नॉन-ब्लॉकिंग" ईवेंट लूप शुरू करता है, जो प्रत्येक श्रोता को सुनने के लिए ज़िम्मेदार होता है, लिखने के समय (29 जुलाई, 2017) श्रोता की कोई शार्डिंग नहीं होती है, नए प्राप्त करते हैं कनेक्शन, कनेक्ट करने के लिए फ़िल्टर स्टैक का एक उदाहरण बनाना और कनेक्शन के जीवनकाल में सभी I / O संचालन को संसाधित करना। फिर से, यह अधिकांश कनेक्शन प्रोसेसिंग कोड को लिखने की अनुमति देता है जैसे कि यह एकल-थ्रेडेड था।
फ़ाइल फ्लशर: प्रत्येक फाइल जो एनवॉय लिखता है, मुख्य रूप से लॉग्स एक्सेस करता है, वर्तमान में एक स्वतंत्र अवरोधक स्ट्रीम है। यह इस तथ्य के कारण है कि फ़ाइल सिस्टम द्वारा कैश की गई फ़ाइलों को लिखना, यहां तक कि O_NONBLOCK का उपयोग करते O_NONBLOCK , कभी-कभी अवरुद्ध किया जा सकता है (आह)। जब श्रमिक थ्रेड्स को फ़ाइल में लिखने की आवश्यकता होती है, तो डेटा को वास्तव में मेमोरी में एक बफर में ले जाया जाता है, जहां इसे अंततः फ़ाइल फ्लश स्ट्रीम के माध्यम से फ्लश किया जाता है। यह कोड का एक क्षेत्र है जहां तकनीकी रूप से सभी श्रमिक थ्रेड्स मेमोरी बफ़र को भरने की कोशिश करते समय एक ही लॉक को ब्लॉक कर सकते हैं।

कनेक्शन संभालना

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

एक बार एक कार्यकर्ता धागे पर एक कनेक्शन स्वीकार किए जाने के बाद, यह इस धागे को कभी नहीं छोड़ता है कनेक्शन के सभी आगे की प्रक्रिया पूरी तरह से श्रमिक धागे में संसाधित होती है, जिसमें किसी भी अग्रेषण व्यवहार शामिल है।

इसके कई महत्वपूर्ण परिणाम हैं:

Envoy में सभी कनेक्शन पूल एक वर्कफ़्लो में हैं। इस प्रकार, हालांकि HTTP / 2 कनेक्शन पूल एक बार में प्रत्येक अपस्ट्रीम होस्ट के लिए केवल एक ही कनेक्शन बनाते हैं, यदि चार वर्कर थ्रेड हैं, तो स्थिर अवस्था में अपस्ट्रीम होस्ट के लिए चार HTTP / 2 कनेक्शन होंगे।
एनवॉय इस तरह से काम करता है क्योंकि सब कुछ एक वर्कफ़्लो में संग्रहीत करके, लगभग सभी कोड को बिना अवरुद्ध किए लिखा जा सकता है और जैसे कि यह एकल-थ्रेडेड था। यह डिज़ाइन बहुत सारे कोड को आसान बनाता है और लगभग असीमित संख्या में वर्कफ़्लोज़ के लिए अविश्वसनीय रूप से अच्छी तरह से स्केल करता है।
हालांकि, मुख्य निष्कर्षों में से एक यह है कि मेमोरी पूल और कनेक्शन दक्षता के दृष्टिकोण से, यह वास्तव में --concurrency पैरामीटर को कॉन्फ़िगर करने के लिए बहुत महत्वपूर्ण है। आवश्यकता से अधिक वर्कर थ्रेड्स होने से मेमोरी लॉस होगा, अधिक निष्क्रिय कनेक्शन बनाने और कनेक्शन पूल में आने की गति को धीमा कर देगा। Lyft में, हमारे दूत साइडकार कंटेनर बहुत कम संगामिति के साथ काम करते हैं, इसलिए प्रदर्शन लगभग उन सेवाओं के बराबर है जो वे बैठते हैं। हम एन्वॉय को एक एज प्रॉक्सी (एज) के रूप में चलाते हैं, जो केवल अधिकतम समरूपता के साथ है।

गैर-अवरुद्ध का क्या अर्थ है?

"गैर-अवरुद्ध" शब्द का उपयोग अब तक कई बार चर्चा में किया गया है कि मुख्य और कार्यकर्ता सूत्र कैसे काम करते हैं। सभी कोड में लिखा है कि कुछ भी कभी भी अवरुद्ध नहीं है। हालांकि, यह पूरी तरह से सच नहीं है (जो पूरी तरह से सच नहीं है?)।

दूत कई लंबी प्रक्रिया वाले ताले का उपयोग करता है:

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

थ्रेड स्थानीय भंडारण

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

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

टीएलएस (थ्रेड लोकल स्टोरेज) एनवॉय सिस्टम निम्नानुसार काम करता है:

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

हालांकि यह एक बहुत ही सरल और अविश्वसनीय रूप से शक्तिशाली प्रतिमान है, यह RCU अवरोधन (रीड-कॉपी-अपडेट) की अवधारणा के समान है। संक्षेप में, वर्कफ़्लो कभी भी रन टाइम में टीएलएस स्लॉट्स में कोई डेटा परिवर्तन नहीं देखता है। परिवर्तन केवल काम की घटनाओं के बीच बाकी की अवधि के दौरान होता है।

दूत इसका दो अलग-अलग तरीकों से उपयोग करता है:

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

क्लस्टर अद्यतन सूत्रण

इस खंड में, मैं वर्णन करूंगा कि कैसे क्लस्टर का प्रबंधन करने के लिए टीएलएस (थ्रेड स्थानीय भंडारण) का उपयोग किया जाता है। क्लस्टर प्रबंधन में एक्सडीएस और / या डीएनएस एपीआई प्रसंस्करण, साथ ही साथ स्वास्थ्य की जाँच भी शामिल है।

क्लस्टर प्रवाह प्रबंधन में निम्नलिखित घटक और चरण शामिल हैं:

क्लस्टर मैनेजर एनवॉय के भीतर एक घटक है जो सभी ज्ञात क्लस्टर अपस्ट्रीम, सीडीएस (क्लस्टर डिस्कवरी सर्विस) एपीआई, एसडीएस (सीक्रेट डिस्कवरी सर्विस) और ईडीएस (एंडपॉइंट डिस्कवरी सर्विस), डीएनएस और सक्रिय बाहरी जांच का प्रबंधन करता है। स्वास्थ्य (स्वास्थ्य की जाँच)। वह प्रत्येक अपस्ट्रीम क्लस्टर का एक "अंततः सुसंगत" प्रतिनिधित्व बनाने के लिए जिम्मेदार है जिसमें खोजे गए मेजबान, साथ ही स्वास्थ्य की स्थिति भी शामिल है।
स्वास्थ्य परीक्षक एक सक्रिय स्वास्थ्य जांच करता है और स्वास्थ्य प्रबंधक में क्लस्टर प्रबंधक के परिवर्तनों पर रिपोर्ट करता है।
CDS (क्लस्टर डिस्कवरी सेवा) / SDS (सीक्रेट डिस्कवरी सर्विस) / EDS (समापन बिंदु डिस्कवरी सेवा) / DNS क्लस्टर सदस्यता निर्धारित करने के लिए किया जाता है। राज्य परिवर्तन क्लस्टर प्रबंधक को दिया जाता है।
प्रत्येक वर्कफ़्लो लगातार एक ईवेंट लूप चलाता है।
जब क्लस्टर प्रबंधक निर्धारित करता है कि क्लस्टर के लिए स्थिति बदल गई है, तो यह एक नया रीड-ओनली क्लस्टर स्नैपशॉट बनाता है और प्रत्येक कार्यकर्ता थ्रेड पर भेजता है।
अगले निष्क्रिय अवधि के दौरान, वर्कफ़्लो समर्पित टीएलएस स्लॉट में स्नैपशॉट को अपडेट करेगा।
एक I / O घटना के दौरान जिसे होस्ट को लोड संतुलन के लिए निर्धारित करना चाहिए, लोड बैलेंसर एक टीएलएस स्लॉट (थ्रेड स्थानीय भंडारण) को होस्ट जानकारी प्राप्त करने का अनुरोध करेगा। इसके लिए किसी ताले की आवश्यकता नहीं है। यह भी ध्यान दें कि टीएलएस अपग्रेड के दौरान घटनाओं को भी ट्रिगर कर सकता है, ताकि बैलेंसर्स और अन्य घटकों को कैश, डेटा संरचनाओं इत्यादि को फिर से जोड़ा जा सके। यह इस पद के दायरे से परे है, लेकिन कोड में विभिन्न स्थानों पर उपयोग किया जाता है।

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

अन्य सबसिस्टम जो टीएलएस का उपयोग करते हैं

एनएलओ में टीएलएस (थ्रेड लोकल स्टोरेज) और आरसीयू (कॉपी अपडेट पढ़ें) का व्यापक रूप से उपयोग किया जाता है।

उपयोग के उदाहरण:

निष्पादन के दौरान कार्यक्षमता बदलने की व्यवस्था: सक्षम कार्यक्षमता की वर्तमान सूची की गणना मुख्य थ्रेड में की जाती है। प्रत्येक वर्कफ़्लो को RCU शब्दार्थ का उपयोग करते हुए केवल-पढ़ने के लिए स्नैपशॉट के साथ प्रदान किया जाता है।
रूट टेबल की जगह : आरडीएस (रूट डिस्कवरी सर्विस) द्वारा प्रदान किए गए रूट टेबल के लिए, रूट टेबल मुख्य धागे में बनाई गई हैं। बाद में RCU शब्दार्थ (रीड कॉपी अपडेट) का उपयोग करके प्रत्येक वर्कफ़्लो को केवल-पढ़ने के लिए स्नैपशॉट प्रदान किया जाएगा। यह रूट टेबल को परमाणु रूप से कुशल बनाता है।
HTTP हैडर कैशिंग: जैसा कि यह पता चला है, प्रत्येक अनुरोध के लिए HTTP हेडर की गणना (जब ~ 25K + RPS प्रति कोर प्रदर्शन) काफी महंगा है। दूत केंद्रीय रूप से हर आधे सेकंड में हेडर की गणना करता है और उसे टीएलएस और आरसीयू के माध्यम से हर कर्मचारी को प्रदान करता है।

अन्य मामले भी हैं, लेकिन पिछले उदाहरणों में टीएलएस का उपयोग करने के लिए एक अच्छी समझ प्रदान की जानी चाहिए।

ज्ञात प्रदर्शन नुकसान

हालाँकि एन्वॉय काफी अच्छी तरह से काम करता है, कुछ प्रसिद्ध क्षेत्र हैं जिन्हें बहुत उच्च संगति और बैंडविड्थ के साथ उपयोग करने पर ध्यान देने की आवश्यकता है:

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

निष्कर्ष (निष्कर्ष)

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

जैसा कि मैंने संक्षेप में ट्विटर पर उल्लेख किया है, उपयोगकर्ता मोड में पूरी तरह कार्यात्मक नेटवर्क स्टैक के ऊपर एक डिज़ाइन भी चल सकता है, जैसे कि डीपीडीके (डेटा प्लेन डेवलपमेंट किट), जो पूर्ण एल 7 प्रसंस्करण के साथ प्रति सेकंड लाखों अनुरोधों को संसाधित करने के लिए नियमित सर्वर का कारण बन सकता है। यह देखना बहुत दिलचस्प होगा कि अगले कुछ वर्षों में क्या बनाया जाएगा।

एक अंतिम त्वरित टिप्पणी: मुझे कई बार पूछा गया है कि हमने दूत के लिए C ++ क्यों चुना। कारण, पहले की तरह, यह अभी भी एकमात्र व्यापक रूप से बोली जाने वाली औद्योगिक स्तर की भाषा है जिस पर इस पोस्ट में वर्णित वास्तुकला का निर्माण करना है। C ++ निश्चित रूप से सभी के लिए या कई परियोजनाओं के लिए भी उपयुक्त नहीं है, लेकिन कुछ निश्चित मामलों के लिए यह अभी भी काम पाने के लिए (काम पाने के लिए) एकमात्र उपकरण है।

कोड के लिंक

इस पोस्ट में चर्चा की गई इंटरफेस और हेडर कार्यान्वयन वाली फाइलों के लिंक:

[अनुवाद] एन्वॉय थ्रेडिंग मॉडल