2010-01-14 15 views
11

मैं विंडोज़ पर stdout से संबंधित डेटा सीमाओं पर कुछ जानकारी खोजने की कोशिश कर रहा हूं। मुझे एमएसडीएन पर जानकारी नहीं मिल रही है।क्या स्टडआउट से जुड़ा एक बफर आकार है?

  1. क्या कोई सीमा है कि stdout पर कितना डेटा लिखा जा सकता है? यदि हां, तो सीमा समाप्त होने पर क्या होता है? क्या डेटा खो गया है?

  2. यदि स्टडआउट रीडायरेक्ट किया गया है (उदाहरण के लिए, नेट से प्रक्रिया लॉन्च करके और ProcessStartInfo.RedirectStandardOutput प्रॉपर्टी का उपयोग करके), क्या इसका कोई प्रभाव नहीं है कि डेटा कितना लिखा जा सकता है? जैसा कि मैंने कॉलिंग प्रक्रिया में stdout स्ट्रीम से पढ़ा है, क्या यह सीमाओं को प्रभावित करता है?

  3. क्या ये सीमाएं नामित पाइपों से संबंधित हैं?

उत्तर

19

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

.NET ने Process.OutputDataReceived और Process.ErrorDataReceived के साथ ईवेंट-संचालित दृष्टिकोण की अनुमति देकर थोड़ा आसान बना दिया है।

1) जॉन: यह आप को ध्यान में रखना दो धागे (एक stdout को पढ़ने के लिए, एक stderr को पढ़ने के लिए) बस को अवरुद्ध करने से प्रक्रिया रखने के लिए ...

+1

का बफर है जो मैंने पोस्ट किए गए से अधिक उपयोगी है। अपना खुद का पोस्ट विज्ञापन आपको वोट दे रहा है। – David

+0

अब यह एक आसान सुविधा है। मुझे आश्चर्य है कि जावा किसी दिन ऐसा कुछ जोड़ देगा। –

+0

(+1) यह शायद .NET परिप्रेक्ष्य के लिए कहीं अधिक उपयोगी है क्योंकि मुझे यकीन है कि किए गए निर्णय प्रोग्रामर के लिए चीजों को सरल बनाना है - हालांकि सीडी में भी stdout काफी सरल (डिफ़ॉल्ट रूप से) है। –

3

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

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

3) नामित पाइप अनिवार्य रूप से एक बफर हैं जो ओएस बनाए रखता है जिसे लिखा जा सकता है और पढ़ा जा सकता है - यानी, वे एक फाइल की तरह हैं जो आप एक प्रक्रिया से लिख सकते हैं और दूसरे में से पढ़ सकते हैं, वास्तव में बिना डिस्क पर एक फाइल रखने के ऊपर। प्रक्रियाओं के बीच संचार के लिए बहुत आसान है, लेकिन बफरिंग/पूर्ण बफर के साथ सभी I/O सीमाएं अभी भी लागू होती हैं।

3

stdout में 1024 बाइट्स

+2

क्या आपके पास इस दावे का स्रोत है? – Zero3

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