हमें नई प्रक्रियाएँ बनाने के लिए कांटे की आवश्यकता क्यों है?


95

यूनिक्स में जब भी हम एक नई प्रक्रिया बनाना चाहते हैं, तो हम वर्तमान प्रक्रिया को कांट-छांट करते हैं, एक नई बाल प्रक्रिया का निर्माण करते हैं जो कि मूल प्रक्रिया के समान है; फिर हम नई प्रक्रिया के लिए मूल प्रक्रिया से सभी डेटा को बदलने के लिए एक निष्पादन प्रणाली कॉल करते हैं।

हम पहली जगह में मूल प्रक्रिया की एक प्रति क्यों बनाते हैं और सीधे नई प्रक्रिया नहीं बनाते हैं?


जवाबों:


61

संक्षिप्त उत्तर है, forkयूनिक्स में है क्योंकि उस समय मौजूदा प्रणाली में फिट होना आसान था, और क्योंकि बर्कले में एक पूर्ववर्ती प्रणाली ने कांटे की अवधारणा का उपयोग किया था।

से यूनिक्स समय सहभाजन प्रणाली का विकास (प्रासंगिक पाठ किया गया है पर प्रकाश डाला ):

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

1) प्रक्रिया तालिका का विस्तार

2) पहले से मौजूद स्वैप IO प्राइमेटिव का उपयोग करते हुए, एक कांटा कॉल की डिस्क जो वर्तमान प्रक्रिया को डिस्क स्वैप क्षेत्र में कॉपी करती है, और प्रक्रिया तालिका में कुछ समायोजन करती है।

वास्तव में, PDP-7 की फोर्क कॉल को विधानसभा कोड की 27 लाइनों की आवश्यकता होती है। बेशक, ऑपरेटिंग सिस्टम और उपयोगकर्ता कार्यक्रमों में अन्य परिवर्तनों की आवश्यकता थी, और उनमें से कुछ बल्कि दिलचस्प और अप्रत्याशित थे। लेकिन एक संयुक्त कांटा-निष्पादन काफी अधिक जटिल होता , यदि केवल इसलिए कि निष्पादन ऐसा नहीं होता; शेल द्वारा स्पष्ट आईओ का उपयोग करके इसका कार्य पहले से ही किया गया था।

उस कागज के बाद से, यूनिक्स विकसित हुआ है। forkइसके बाद execप्रोग्राम चलाने का एकमात्र तरीका नहीं है।

  • vfork को उस मामले के लिए अधिक कुशल कांटा बनने के लिए बनाया गया था जहां नई प्रक्रिया कांटा के ठीक बाद एक निष्पादन करने का इरादा रखती है। एक vfork करने के बाद, माता-पिता और बच्चे की प्रक्रिया समान डेटा स्थान साझा करते हैं, और माता-पिता की प्रक्रिया को तब तक निलंबित कर दिया जाता है जब तक कि बच्चा प्रक्रिया या तो किसी प्रोग्राम को निष्पादित नहीं करता है या बाहर निकल जाता है।

  • posix_spawn एक नई प्रक्रिया बनाता है और किसी एकल सिस्टम कॉल में एक फ़ाइल निष्पादित करता है। यह मापदंडों का एक गुच्छा लेता है जो आपको चुनिंदा कॉलर की खुली फ़ाइलों को साझा करने देता है और नई प्रक्रिया के लिए इसके संकेत स्वभाव और अन्य विशेषताओं की प्रतिलिपि बनाता है।


5
अच्छा जवाब है, लेकिन मुझे लगता है कि vfork अब इस्तेमाल नहीं किया जाना चाहिए जोड़ देंगे। प्रदर्शन का अंतर अब मामूली है और इसका उपयोग खतरनाक हो सकता है। इस SO प्रश्न को देखें stackoverflow.com/questions/4856255/…, यह साइट ewontfix.com/7 , और "उन्नत यूनिक्स प्रोग्रामिंग" पृष्ठ 299 vfork के बारे में
राफेल

4
posix_spawn()समान पोस्ट-फोर्क रिप्लेसमेंट नौकरियों को करने के लिए उपयोग करने के लिए आवश्यक मशीन (डेटा संरचना सेटअप) जिसे आसानी से उपयोग किया जा सकता है fork()और इनलाइन कोड fork()उपयोग करने के लिए बहुत सरल होने के लिए एक सम्मोहक तर्क देता है ।
जोनाथन लेफ्लर

34

[मैं यहाँ से अपने उत्तर का हिस्सा दोहराऊंगा ।]

सिर्फ एक कमांड क्यों नहीं है जो खरोंच से एक नई प्रक्रिया बनाता है? क्या यह एक ऐसी चीज की नकल करना बेमानी और अक्षम नहीं है जो केवल तुरंत ही प्रतिस्थापित होने वाली है?

वास्तव में, कि शायद कुछ कारणों के लिए कुशल नहीं होगा:

  1. द्वारा उत्पादित "कॉपी" fork()एक अमूर्त का एक सा है, क्योंकि कर्नेल एक कॉपी-ऑन-राइट सिस्टम का उपयोग करता है ; वास्तव में बनाया जाना है कि सभी एक आभासी स्मृति नक्शा है। यदि कॉपी फिर तुरंत कॉल करता है exec(), तो अधिकांश डेटा जो कॉपी किया गया होता अगर इसे प्रक्रिया की गतिविधि द्वारा संशोधित किया गया होता, तो वास्तव में कभी भी कॉपी / निर्मित नहीं करना पड़ता क्योंकि प्रक्रिया इसके उपयोग की आवश्यकता के लिए कुछ भी नहीं करती है।

  2. बाल प्रक्रिया के विभिन्न महत्वपूर्ण पहलुओं (उदाहरण के लिए, इसका वातावरण) को व्यक्तिगत रूप से दोहराव या संदर्भ के जटिल विश्लेषण के आधार पर सेट करने की आवश्यकता नहीं होती है, आदि वे बस कॉलिंग प्रक्रिया के समान ही माने जाते हैं, और यह काफी सहज प्रणाली है जिससे हम परिचित हैं।

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

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

पॉइंट # 2 यह बताता है कि कांटा का उपयोग करने की संभावना अधिक कुशल क्यों है। एक बच्चे का पर्यावरण उसके माता-पिता से विरासत में मिला है, भले ही यह पूरी तरह से अलग निष्पादन योग्य हो। उदाहरण के लिए, यदि मूल प्रक्रिया एक शेल है, और बच्चा एक वेब ब्राउज़र है, $HOMEतो अभी भी उन दोनों के लिए समान है, लेकिन चूंकि या तो बाद में इसे बदल सकते हैं, ये दो अलग-अलग प्रतियां होनी चाहिए। बच्चे में एक मूल द्वारा निर्मित है fork()

1. एक रणनीति जो बहुत शाब्दिक अर्थ नहीं दे सकती है, लेकिन मेरा कहना है कि एक प्रक्रिया बनाने में डिस्क से मेमोरी में छवि की नकल करने से अधिक शामिल है।


3
हालांकि दोनों बिंदु सही हैं, न तो समर्थन करता है कि दिए गए निष्पादन योग्य से एक नई प्रक्रिया को रीट करने के बजाय फोर्किंग विधि को क्यों चुना गया।
स्काईडान

3
मुझे लगता है कि यह सवाल का जवाब देता है। कांटा का उपयोग किया जाता है, क्योंकि ऐसे मामलों में जहां एक नई प्रक्रिया का निर्माण करना सबसे कुशल तरीका है, इसके बजाय कांटा का उपयोग करने की लागत तुच्छ है (संभावित रूप से प्रक्रिया निर्माण लागत का 1% से कम)। दूसरी ओर, ऐसे कई स्थान हैं जहां कांटा नाटकीय रूप से एक एपीआई के बहुत अधिक कुशल या कहीं अधिक सरल है (जैसे फ़ाइल हैंडल को संभालना)। यूनिक्स का निर्णय केवल एक एपीआई का समर्थन करना था, जिससे विनिर्देश सरल हो गया।
Cort Ammon

1
@SkyDan आप सही हैं, यह और अधिक करने के लिए एक जवाब है क्यों नहीं बजाय क्यों जो मैं व्याख्या मतलब करने के लिए नहीं सिर्फ इतना है कि इस सबसे आसान विकल्प था, लेकिन यह भी कि यह शायद था - है, जो मार्क Plotnick अधिक सीधे जवाब देती है सबसे कारगर पसंद (डेनिस रिची बोली के अनुसार: "PDP-7 की फोर्क कॉल को विधानसभा की ठीक 27 पंक्तियों की आवश्यकता थी ... निष्पादन ऐसा नहीं होता था; इसका कार्य पहले से ही किया गया था")। तो यह "क्यों नहीं" वास्तव में दो रणनीतियों के बारे में एक पेशी है जिसमें एक सतही सरल और अधिक कुशल दिखाई देता है, जब शायद यह नहीं है (गवाह का संदिग्ध भाग्य ...
Goldilocks

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

2
आपका जवाब हार्डवेयर सुधारों को संदर्भित करता है: वर्चुअल मेमोरी, कॉपी-ऑन-राइट। इससे पहले, forkवास्तव में सभी प्रक्रिया मेमोरी की नकल की, और यह बहुत महंगा था।
बमर

6

मुझे लगता है कि यूनिक्स के पास forkनई प्रक्रियाओं को बनाने का केवल एक कारण था, यूनिक्स दर्शन का एक परिणाम है

वे एक फ़ंक्शन का निर्माण करते हैं जो एक चीज़ को अच्छी तरह से करता है। यह एक बच्चे की प्रक्रिया बनाता है।

नई प्रक्रिया के साथ जो करता है वह प्रोग्रामर तक होता है। वह exec*कार्यों में से एक का उपयोग कर सकता है और एक अलग कार्यक्रम शुरू कर सकता है, या वह निष्पादन का उपयोग नहीं कर सकता है और एक ही कार्यक्रम के दो उदाहरणों का उपयोग कर सकता है, जो उपयोगी हो सकता है।

इसलिए आपको स्वतंत्रता का एक बड़ा हिस्सा मिलता है क्योंकि आप इसका उपयोग कर सकते हैं

  1. निष्पादन के बिना कांटा *
  2. निष्पादन के साथ कांटा * या
  3. बस निष्पादित * कांटा के बिना

और इसके अलावा आपको केवल forkऔर उस exec*फंक्शन कॉल्स को याद रखना होगा , जो 1970 के दशक में आपको करना था।


3
मैं समझता हूं कि कांटे कैसे काम करते हैं, और उनका उपयोग कैसे करें। लेकिन मैं एक नई प्रक्रिया क्यों बनाना चाहूंगा, जब मैं एक ही काम कर सकता हूं लेकिन कम प्रयास के साथ? उदाहरण के लिए, मेरे शिक्षक ने मुझे एक असाइनमेंट दिया था जहाँ मुझे यह सुनिश्चित करने के लिए कि प्रत्येक संख्या को आर्गव करने के लिए पास किया गया था, यदि नंबर प्राइम है तो एक प्रक्रिया बनानी होगी। लेकिन ऐसा नहीं है कि बस एक ही बात का एक चक्कर? मैं सिर्फ एक सरणी का उपयोग कर सकता हूं और प्रत्येक नंबर के लिए एक फ़ंक्शन का उपयोग कर सकता हूं ... तो हम मुख्य प्रक्रिया में सभी प्रसंस्करण करने के बजाय, बाल प्रक्रियाएं क्यों बनाते हैं?
user1534664

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

5

प्रक्रिया निर्माण के दो दर्शन हैं: विरासत के साथ कांटा, और तर्कों के साथ बनाते हैं। यूनिक्स कांटा का उपयोग करता है, जाहिर है। (OSE, उदाहरण के लिए, और VMS बनाने की विधि का उपयोग करते हैं।) यूनिक्स में कई अंतर्निहित विशेषताएँ हैं, और अधिक समय-समय पर जोड़ी जाती हैं। विरासत के माध्यम से, इन नई विशेषताओं को परिवर्तनशील कार्यक्रमों के बिना जोड़ा जा सकता है! एक बनाने के साथ तर्क मॉडल का उपयोग करना, नई विशेषताओं को जोड़ने का मतलब होगा कि कॉल करने के लिए नए तर्क जोड़ना। यूनिक्स मॉडल सरल है।

यह अत्यधिक उपयोगी कांटा-रहित-निष्पादन मॉडल का भी समर्थन करता है, जहां एक प्रक्रिया खुद को कई टुकड़ों में विभाजित कर सकती है। यह महत्वपूर्ण था जब async I / O का कोई रूप नहीं था, और सिस्टम में कई CPU का लाभ उठाते समय उपयोगी होता है। (प्री-थ्रेड्स।) मैंने पिछले कुछ वर्षों में यह किया है, यहां तक ​​कि हाल ही में। संक्षेप में यह एक कार्यक्रम में कंटेनर-izing एकाधिक 'कार्यक्रमों' की अनुमति देता है, इसलिए भ्रष्टाचार या संस्करण बेमेल के लिए कोई जगह नहीं है, आदि।

कांटा / निष्पादन मॉडल एक विशिष्ट बच्चे के लिए एक मौलिक अजीब वातावरण प्राप्त करने की क्षमता की पुष्टि करता है, जो कांटा और निष्पादन के बीच स्थापित होता है। खासतौर पर विरासत में मिली फाइल डिस्क्रिप्टर जैसी चीजें। (Stdio fd's का एक्सटेंशन।) क्रिएट मॉडल कुछ भी बनाने की क्षमता प्रदान नहीं करता है जो क्रिएट कॉल के रचनाकारों द्वारा कल्पना नहीं की गई थी।

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


फ़ाइल डिस्क्रिप्टर "stdio का विस्तार" नहीं है; stdio फ़ाइल पॉइंटर्स फ़ाइल डिस्क्रिप्टर के आसपास एक आवरण है। फ़ाइल विवरणकर्ता पहले आए, और वे मौलिक यूनिक्स I / O हैंडल हैं। लेकिन, अन्यथा, यह एक अच्छा बिंदु है।
स्कॉट

2

कांटा () फ़ंक्शन केवल पिता प्रक्रिया की प्रतिलिपि बनाने के लिए नहीं है, यह एक मान लौटाता है जो संदर्भित करता है कि प्रक्रिया पिता या पुत्र प्रक्रिया है, नीचे दी गई छवि बताती है कि आप एक पिता और पिता के रूप में कांटा () का उपयोग कैसे कर सकते हैं बेटा:

यहाँ छवि विवरण दर्ज करें

जैसा कि दिखाया गया है कि जब प्रक्रिया पिता का कांटा है () बेटे की प्रक्रिया आईडी PID लौटाता है तो वह वापस आ जाती है0

उदाहरण के लिए आप इसका उपयोग कर सकते हैं यदि आपके पास एक प्रक्रिया (वेब ​​सर्वर) है जो अनुरोध प्राप्त करता है और प्रत्येक अनुरोध पर यह son processइस अनुरोध को संसाधित करने के लिए बनाता है , यहां पिता और उसके बेटों के अलग-अलग काम हैं।

एसओ, कोई प्रक्रिया की प्रतिलिपि नहीं चलाना कांटा () के रूप में सटीक बात नहीं है।


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

1
मैं स्काईडैन से सहमत हूं - यह सवाल का जवाब नहीं देता है। posix_spawn कुछ हद तक एक कट्टरपंथी संस्करण है जिसकी कल्पना शायद 30 साल पहले ( पोज़िक्स से पहले) fork_execve फ़ंक्शन के रूप में की गई हो ; वह जो एक नई प्रक्रिया बनाता है, अपनी छवि को एक निष्पादन योग्य से आरंभ करता है, बिना पैरेंट प्रक्रिया की छवि को कॉपी किए बिना भी (तर्क सूची, पर्यावरण को छोड़कर, और प्रक्रिया विशेषताएँ (जैसे, वर्किंग डायरेक्टरी)), और रिटर्न देता है कॉलर को नई प्रक्रिया की पीआईडी ​​(मूल प्रक्रिया)
स्कॉट

1
एक बच्चे को "माता-पिता" जानकारी पास करने के अन्य तरीके हैं। रिटर्न वैल्यू तकनीक बस ऐसा करने का सबसे कुशल तरीका है fork यदि आप यह मान लें कि आप forkपहली जगह में चाहते हैं
Cort Ammon

0

I / O पुनर्निर्देशन कांटा के बाद और निष्पादन से पहले सबसे आसानी से लागू किया जाता है। बच्चा, जागरूक होने के नाते, यह बच्चे के विवरणों को बंद कर सकता है, नए लोगों को खोल सकता है, माता-पिता को प्रभावित किए बिना सभी को सही fd नंबर आदि पर पाने के लिए उन्हें () या dup2 () जोड़ सकता है। ऐसा करने के बाद, और शायद किसी भी वांछित पर्यावरण परिवर्तनशील परिवर्तन (माता-पिता को प्रभावित नहीं करना), यह नए प्रोग्राम को अनुरूप वातावरण में निष्पादित कर सकता है।


यहां आप जो कुछ भी कर रहे हैं, वह थोड़ा और अधिक विस्तार के साथ जिम कैथे के उत्तर के तीसरे पैराग्राफ को दोहरा रहा है ।
स्कॉट

-2

मुझे लगता है कि हर कोई जानता है कि कांटा कैसे काम करता है, लेकिन सवाल यह है कि हमें कांटा का उपयोग करके माता-पिता की सटीक नकल बनाने की आवश्यकता क्यों है? उत्तर ==> सर्वर का एक उदाहरण लें (कांटा रहित), जबकि क्लाइंट -1 सर्वर तक पहुंच रहा है, अगर उसी समय दूसरा क्लाइंट -2 आ जाता है और सर्वर एक्सेस करना चाहता है, लेकिन सर्वर नए आने की अनुमति नहीं देता है क्लाइंट -2 क्योंकि सर्वर क्लाइंट -1 की सेवा करने में व्यस्त है, इसलिए क्लाइंट -2 को इंतजार करना पड़ता है। क्लाइंट -1 के लिए सभी सेवाएं समाप्त होने के बाद, क्लाइंट -2 अब सर्वर तक पहुंचने में सक्षम है। अब विचार करें कि क्या एक ही समय में क्लाइंट -3 आता है, इसलिए क्लाइंट -3 को क्लाइंट -2 तक सभी सेवाओं को पूरा होने तक इंतजार करना पड़ता है। उस परिदृश्य को देखें जहां हजारों क्लाइंट को एक ही समय में सर्वर तक पहुंचने की आवश्यकता होती है ... फिर सभी ग्राहकों को प्रतीक्षा (सर्वर व्यस्त है !!)।

इसे सर्वर की सटीक डुप्लिकेट कॉपी (यानी बच्चा) बनाने से परहेज किया जाता है, जहां प्रत्येक बच्चा (जो कि अपने माता-पिता (सर्वर) की सटीक डुप्लीकेट कॉपी है) नए आने वाले क्लाइंट को समर्पित है, इस प्रकार एक साथ सभी क्लाइंट एक समान पहुंचते हैं सर्वर।


यही कारण है कि सर्वर प्रक्रियाओं को एकल-थ्रेडेड नहीं होना चाहिए, क्लाइंट अनुरोधों को लगातार संभालते हुए जब उन्हें समवर्ती रूप से संभाला जा सकता है - जैसे, अलग-अलग प्रक्रियाओं में। लेकिन बहु-थ्रेडेड सर्वर मॉडल को एक श्रोता प्रक्रिया के साथ आसानी से लागू किया जा सकता है जो ग्राहकों से अनुरोधों को स्वीकार करता है और एक नई प्रक्रिया बनाता है जिसमें ग्राहक-सेवा कार्यक्रम चलाना है। एकमात्र लाभ जो forkकि मूल प्रक्रिया को कॉपी करने वाली कॉल द्वारा पेश किया जाता है, वह यह है कि आपके पास दो अलग-अलग कार्यक्रम नहीं हैं - लेकिन अलग-अलग प्रोग्राम (जैसे inetd) होने से सिस्टम अधिक मॉड्यूलर हो सकता है।
स्कॉट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.