फ़ाइल इतनी महंगी संसाधन क्यों संभालती है?

Question

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

Answer 1

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

इसके अलावा, सच बोलने के लिए, पुरानी आदतें मर जाती हैं। फाइल हैंडल महंगी होती थीं और अभी भी ऐतिहासिक कारणों के लिए इस तरह माना जाता है।

Answer 2

यह केवल फाइल हैंडल की मात्रा नहीं है, यह कभी-कभी जब कुछ मोड में उपयोग किया जाता है, तो वे अन्य कॉलर्स को उसी फ़ाइल तक पहुंचने में सक्षम होने से रोक सकते हैं।

Answer 3

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

Answer 4

मुझे नहीं लगता कि वे आवश्यक रूप से महंगी हैं - यदि आपका आवेदन केवल कुछ अनैतिक लोगों को खोलता है तो यह सिस्टम को मार नहीं देगा। जैसे कि आप सी ++ में केवल कुछ तारों को रिसाव करते हैं, कोई भी ध्यान नहीं देगा, जब तक कि वे बहुत सावधानी से नहीं देख रहे हों। यह कहाँ हो जाता है एक समस्या है:

• यदि आप सैकड़ों या हजारों
• रिसाव यदि फ़ाइल खुला होने उस फ़ाइल पर होने वाली (अन्य अनुप्रयोगों को खोलने या फ़ाइल को नष्ट करने में सक्षम नहीं हो सकता है)
से अन्य कार्यों से बचाता है
• यह ढीलापन का संकेत है - यदि आपका प्रोग्राम ट्रैक का उपयोग नहीं कर सकता है और इसका उपयोग कर रहा है या इसका उपयोग बंद कर रहा है, तो प्रोग्राम में अन्य समस्याएं क्या हैं? कभी-कभी एक छोटा रिसाव एक बड़े रिसाव में बदल जाता है जब कुछ छोटे बदलाव या उपयोगकर्ता पहले से थोड़ा अलग करता है।

Answer 5

प्रैक्टिस में, ऐसा नहीं किया जा सकता है क्योंकि ओएस को विभिन्न प्रक्रियाओं द्वारा उपयोग किए जाने वाले हैंडल का ट्रैक रखने के लिए बहुत अधिक मेमोरी ओवरहेड आवंटित करना होगा। एक उदाहरण सी कोड के रूप में नीचे मैं एक साधारण ओएस प्रक्रिया एक उदाहरण के लिए एक परिपत्र कतार में संग्रहीत संरचना का प्रदर्शन करेंगे पता चला ...

 
struct ProcessRecord{ 
    int ProcessId; 
    CPURegs cpuRegs; 
    TaskPointer **children; 
    int *baseMemAddress; 
    int sizeOfStack; 
    int sizeOfHeap; 
    int *baseHeapAddress; 
    int granularity; 
    int time; 
    enum State{ Running, Runnable, Zombie ... }; 
    /* ...few more fields here... */ 
    long *fileHandles; 
    long fileHandlesCount; 
}proc; 

कल्पना कीजिए कि fileHandles पूर्णांकों की एक सरणी है जो प्रत्येक पूर्णांक शामिल करने के लिए एक सूचक है ओएस की तालिका में ऑफ़सेट के लिए स्थान (शायद एन्कोडेड प्रारूप में) जहां फ़ाइलों को डिस्क पर संग्रहीत किया जाता है।

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

मुझे आशा है कि इससे आपको यह समझने में मदद मिलेगी कि यह क्यों लागू नहीं किया गया है और न ही व्यावहारिक है।

आशा है कि यह समझ में आता है, सर्वश्रेष्ठ संबंध, टॉम।

Answer 6

लिनक्स प्रतिमान सॉकेट में फ़ाइल वर्णनकर्ता हैं। जितनी जल्दी हो सके टीसीपी बंदरगाहों को मुक्त करने के लिए निश्चित फायदे हैं।