कांटा () और vfork () के बीच अंतर क्या है?

13

मैं कांटा () और vfork () के बीच अंतर को विस्तार से समझना चाहूंगा। मैं मैन पेज को पूरी तरह से पचा नहीं पा रहा था।

मैं अपने एक सहकर्मी की टिप्पणी को भी स्पष्ट करना चाहूंगा " वर्तमान लिनक्स में, कोई vfork () नहीं है, भले ही आप इसे कॉल करें, यह आंतरिक रूप से कांटा () को कॉल करेगा ।"

linux system-calls fork

— सेन
स्रोत

24

मैन पेज आमतौर पर संदर्भ दस्तावेज होते हैं। वैचारिक व्याख्याओं के लिए विकिपीडिया एक बेहतर स्थान है।

कांटा एक प्रक्रिया को दोहराता है: यह एक बच्चे की प्रक्रिया बनाता है जो मूल प्रक्रिया के लगभग समान है (सबसे स्पष्ट अंतर यह है कि नई प्रक्रिया में एक अलग प्रक्रिया आईडी है)। विशेष रूप से, कांटा (वैचारिक रूप से) सभी मूल प्रक्रिया की मेमोरी को कॉपी करना चाहिए।

जैसा कि यह बल्कि महंगा है, vfork का आविष्कार एक सामान्य विशेष मामले को संभालने के लिए किया गया था जहाँ प्रतिलिपि आवश्यक नहीं है। अक्सर, बच्चे की प्रक्रिया में पहली चीज एक नई कार्यक्रम छवि को लोड करना होती है, इसलिए ऐसा होता है:

if (fork()) {
    # parent process …
} else {
    # child process (with a new copy of the process memory)
    execve("/bin/sh", …);  # discard the process memory
}

execveकॉल लोड एक नई निष्पादन योग्य प्रोग्राम, और प्रतिस्थापित कर देता है नई निष्पादन योग्य का कोड और एक ताजा डेटा स्मृति द्वारा प्रक्रिया के कोड और डेटा स्मृति। तो forkसभी द्वारा बनाई गई पूरी मेमोरी कॉपी कुछ भी नहीं थी।

इस प्रकार vforkकॉल का आविष्कार किया गया था। यह मेमोरी की एक प्रति नहीं बनाता है। इसलिए vforkयह सस्ता है, लेकिन इसका उपयोग करना मुश्किल है क्योंकि आपको यह सुनिश्चित करना है कि आप बच्चे की प्रक्रिया में स्टैक या हीप स्पेस में से किसी का उपयोग न करें। ध्यान दें कि पढ़ना भी एक समस्या हो सकती है, क्योंकि मूल प्रक्रिया चलती रहती है। उदाहरण के लिए, यह कोड टूट गया है (यह निर्भर करता है कि बच्चे या माता-पिता को पहले एक बार स्लाइस मिलता है या नहीं)

if (vfork()) {
    # parent process
    cmd = NULL; # modify the only copy of cmd
} else {
    # child process
    execve("/bin/sh", "sh", "-c", cmd, (char*)NULL);  # read the only copy of cmd
}

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

लिनक्स vfork को बनाए रखता है। forkसिस्टम कॉल अभी भी प्रक्रिया के आभासी स्मृति तालिका की एक प्रतिलिपि बनाने चाहिए, भले ही यह वास्तविक स्मृति नकल नहीं करता है; vforkयह भी करने की जरूरत नहीं है। अधिकांश अनुप्रयोगों में प्रदर्शन सुधार नगण्य है।

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत

1

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

— सेन

@ सीन: forkएक अलग वर्चुअल मेमोरी मैपिंग बनाने की आवश्यकता है ताकि बाद की कॉपी-ऑन-राइट प्रतियां केवल दो प्रक्रियाओं में से एक को प्रभावित करें।

— गिलेस एसओ- बुराई को रोकना '

क्या आप सुनिश्चित हैं कि मूल प्रक्रिया चल रही है?

— क़ुबूल

2

fork()और vfork()syscalls अलग हैं।

fork()Syscall अलग स्मृति दो समान प्रक्रियाओं उत्पन्न करता है। vfork()Syscall दो प्रक्रियाओं है कि का हिस्सा एक ही स्मृति उत्पन्न करता है।

vfork()माता-पिता के साथ बच्चे की समाप्ति की प्रतीक्षा करेंगे। माता-पिता को उन चर से विरासत में मिला है जो कार्यक्रम साझा कर रहे हैं। इसलिए बच्चे को बुलाए जाने के बाद, बच्चे के अंदर संशोधित सभी चर अभी भी माता-पिता के अंदर संशोधित किए जाएंगे।

अधिक जानकारी के लिए यहां क्लिक करें

— योगेश एचटी
स्रोत