2011-02-01 17 views
8

क्या इस तरह के मामले में केवल एक बार फ़ाइल खोलना प्रथागत है?क्या मुझे एक फाइल खोलनी चाहिए या क्या मुझे अक्सर खोलना और बंद करना चाहिए?

#!/usr/bin/env perl 
use warnings; 
use 5.012; 
use autodie; 

my $file = 'my_file'; 

open my $fh, '>>', $file; 
say $fh "Begin"; 
close $fh; 

$SIG{INT} = sub { 
    open my $fh, '>>', $file; 
    say $fh "End"; 
    close $fh; 
    exit 
}; 

my $result; 
while (1) { 
    $result++; 
    # ... 
    # ... 
    # ... 
    open my $fh, '>>', $file; 
    say $fh $result; 
    close $fh; 
    sleep 3; 
} 

उत्तर

20

लघु जवाब: लगभग हमेशा, आप खोलना चाहिए/बंद केवल एक बार नीचे विवरण।

की क्या करना है कि क्या है कि 4 बातों पर निर्भर करता निर्णय:

  1. वहाँ अन्य प्रक्रियाओं है कि फ़ाइल पर लिखने की आवश्यकता हो सकती हैं?

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

  2. क्या ऐसी कई फाइलें हैं जिन्हें आपको खोलने की आवश्यकता है?

    यदि ऐसा है, तो आप बहुत सारी खुली फ़ाइलों के साथ फ़ाइल हैंडल से बाहर हो सकते हैं, इसलिए आपको बंद करने की आवश्यकता है।

  3. प्रोग्राम क्रैश होने पर फ़ाइल में डेटा खोने के लिए आपके पास कितनी सहनशीलता है।

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

  4. क्या आप डिस्क स्पेस से बाहर होने के बाद फ़ाइल को बंद करने में सक्षम नहीं होने के बारे में बहुत परवाह करते हैं?

    यदि ऐसा है, तो जितनी बार आप फ़ाइल को बंद/दोबारा खोलते हैं, फाइल सिस्टम पूरी तरह से खोने के कारण आप खो जाएंगे, इसलिए जो भी आपने पिछले open से लिखा था, वह समाप्त हो गया है।

किसी अन्य परिदृश्य, केवल खोलने/बंद एक बार (अच्छी तरह से, के साथ साथ शायद __DIE__ हैंडलर और END{} ब्लॉक (और समय के बहुमत में अतिरिक्त करीब है, आप की संभावना अन्य स्थितियों में किया जाएगा) में।

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

कृपया ध्यान दें (के बारे में परिदृश्यों # 3/# 4) कि अगर आप किसी भी डेटा को खोने नहीं के बारे में बहुत परवाह, आप पहली जगह में नहीं का उपयोग करना चाहिए फ़ाइल आईओ - एक डेटाबेस या प्रसव की गारंटी देता है के साथ एक संदेश सिस्टम का उपयोग ।

+0

इसके अलावा, आप सभी उद्घाटन और समापन के साथ कितना ओवरहेड सामना करना चाहते हैं - वे लागत मुक्त संचालन नहीं हैं। –

+0

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

+0

@ एसएलॉट - यह जेनेरिक "कचरे सिस्टम संसाधनों" शीर्षक के तहत है, लेकिन मैं थोड़ा विस्तार करूँगा :) – DVK

4

यह सामान्य है, सामान्य प्रोग्रामिंग के लिए, प्रत्येक फ़ाइल को खोलने के लिए और खुले फ़ाइल हैंडल को तब तक रखें जब तक आपकी प्रसंस्करण अभी भी इसके लिए उपयोग न करे।

यह अपवाद तब होगा जब फ़ाइल हैंडलिंग कोड के विशिष्ट भाग (उदाहरण के लिए प्रारंभिकरण और शटडाउन) तक सीमित हो या विशिष्ट और अपेक्षाकृत दुर्लभ घटनाओं (एक सिग्नल हैंडलर कॉन्फ़िगरेशन को फिर से पढ़ने या सांख्यिकीय अद्यतन करने के लिए बंधे हों) डीबगिंग डंप)।

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

संबंधित मुद्दे