2010-01-14 20 views
11

Próbuję znaleźć informacje na temat limitów danych związanych ze stdout w systemie Windows. Nie mogę znaleźć informacji o MSDN.Czy do stdout dołączono rozmiar bufora?

  1. Czy istnieje limit ilości danych zapisywanych na stdout? Jeśli tak, co się stanie, jeśli limit zostanie osiągnięty? Czy dane są utracone?

  2. Jeśli standardowe wyjście jest przekierowywane (na przykład przez uruchomienie procesu z .Net i użycie właściwości ProcessStartInfo.RedirectStandardOutput), czy ma to wpływ na to, ile danych można zapisać? Jak czytam ze strumienia standardowego w procesie wywoływania, czy ma to wpływ na ograniczenia?

  3. Czy te ograniczenia są w jakikolwiek sposób powiązane z nazwanymi rurami?

Odpowiedz

19

To zależy gdzie to się dzieje - ale tak, jeśli przekierować wyjście w .NET można łatwo napotkasz problemy, jeśli nie czytać wyjście. Kiedy bufor się skończy, zapis na stdout w procesie potomnym zostanie zablokowany. Jedną z częstych przyczyn impasu jest proces "rodzica" oczekujący na wyjście "dziecka", a następnie odczytanie wyniku - który nie zadziała, jeśli dziecko potrzebuje rodzica, aby odczytać dane wyjściowe w celu zwolnienia miejsca w buforze.

. NET nieco to ułatwił, umożliwiając sterowanie zdarzeniami za pomocą Process.OutputDataReceived i Process.ErrorDataReceived. Oznacza to, że nie ma potrzeby, aby uruchomić dwa wątki (jeden do zapoznania stdout, stderr jeden do odczytu) tak, aby utrzymać proces blokowaniu ...

+1

To DROGA bardziej przydatna niż to, co napisałem. Usuwam moją własną reklamę pocztową. – David

+0

To przydatna funkcja. Zastanawiam się, czy pewnego dnia Java doda coś takiego. –

+0

(+1) Prawdopodobnie jest to o wiele bardziej przydatne, jeśli chodzi o perspektywę .NET, ponieważ jestem pewien, że podejmowane decyzje mają na celu uproszczenie rzeczy dla programisty - chociaż standardowe wyjście jest również dość proste (domyślnie) w C. –

3

Niektóre rzeczy o których warto pamiętać:

1) Jon ma rację - jeśli zostanie osiągnięty limit bufora, wywołanie zapisu w podprocesie zostanie zablokowane. Musisz drenaż strumienia standardowego, jeśli nie jest przekierowany gdzieś, co spowoduje automatyczne drenaż - jak plik. Rury należy opróżnić, a zazwyczaj, jeśli można "dołączyć" do wyjścia podprocesowego, podłączasz się do rury.

2) I/O do strumienia wyjściowego jest prawdopodobnie buforowane, co oznacza, że ​​jeśli podproces zapisuje informacje na standardowe wyjście bez jawne wywołanie flush(), który jest prawie zawsze tak, że nie może zobaczyć wyjście. Opróżnianie jest automatycznie wywoływane, gdy proces się kończy, więc jeśli jest to krótki mały podproces, powinieneś być w porządku, ale jeśli tak nie jest, nie masz realnego sposobu na wymuszenie wyświetlania jego danych wyjściowych, kiedy tego chcesz.

3) Nazwane potoki są zasadniczo buforem, który system operacyjny obsługuje, do którego można zapisywać i odczytywać - to znaczy, że są jak plik, z którego można pisać z jednego procesu i czytać z innego, bez konieczności narzut posiadania pliku na dysku. Bardzo przydatny do komunikacji między procesami, ale wszystkie ograniczenia We/Wy z buforowaniem/pełne bufory nadal mają zastosowanie.

3

stdout ma bufor 1024 bajtów

+2

Czy masz źródło tego roszczenia? – Zero3

Powiązane problemy