2010-10-02 12 views
8

Questa domanda è stata posta più volte, ma non ho trovato una risposta soddisfacente in nessuna di queste discussioni.Come disattivare il buffer di output in Process.StandardOutput

Sto avviando un processo da riga di comando che produce una misurazione in tempo reale su STDOUT, producendo un nuovo risultato circa ogni secondo. L'utilizzo di System.Diagnostics.Process.StandardOutput comporta un ritardo completamente inaccettabile (oltre 20 secondi) poiché i dati STDOUT funzionano tramite il buffer 4k in Process.StandardOutput StreamReader e non sembra esserci alcun modo per aggirare questo problema.

Calling Process.StandardOutput.BaseStream.Flush() non funziona.

Ho provato a fare una lettura sincrona byte-by-byte di Process.StandardOutput, ma sono ancora 4k dietro l'output effettivo.

Qualcuno può almeno verificare per me che è possibile in qualche modo superare tutti i problemi di buffering che sto avendo con il reindirizzamento di STDOUT e ricevere i dati nella mia applicazione non appena essa sarebbe apparsa nella finestra della shell? Posso ereditare dalla classe Process e cambiare il modo in cui si comporta lo streamreader di StandardOutput? Devo controllare le chiamate WINAPI non elaborate?

In qualche modo, questo deve essere fatto, anche se finisco per scrivere C++ non gestito per avviare l'attività e consumare l'output e collegarlo. Qualsiasi aiuto è molto apprezzato; Sono alla fine del mio spirito ...

Modifica: Sembra che quello che mi serve è un'implementazione .Net delle librerie "expect" che sono disponibili per C/C++, Perl, Python e Java (quelle sono gli unici che ho trovato finora). Qualcuno sa se esiste una tale bestia?

+0

fa schifo non hai mai avuto una buona risposta a questa domanda ... –

+0

Sì. Ho finito per acquisire il codice sorgente al comando esterno e ricompilarlo con il lavaggio del buffer STDOUT esplicito. Mi piacerebbe comunque risolvere il problema originale. Mi sono divertito a scrivere un'implementazione di .Net Expect, ma la ricompilazione dello strumento esterno mi è sembrata un modo migliore per evitare di urlare il mio capo. –

+0

Ho avuto problemi con lo stesso problema. Sto leggendo l'output della console in un thread separato (o in realtà 2: 1 per stderr, 1 per stdout). Come risulta, StandardOutput si limita a bufferare quando si usano chiamate come 'Peek', che restituiscono -1 nel processo. Se si usa semplicemente 'ReadLine' o' Read' con 1 byte, funzionerà bene e non si avranno problemi con il buffering. – atlaste

risposta

1

"[I] c'è un modo per lanciarlo tale [che] non si rende conto che viene reindirizzato?" SÌ: questo è esattamente il dominio di Expect. So di no. Implementazione net; è sicuramente fattibile, anche se ...

+0

Molto impegnativo a causa del modo in cui Windows funziona internamente! (Beh, non con Mono su Unix dove hai accesso a veri e propri terminali virtuali, ma questa è un'altra storia.) Expect for Windows usa una sorta di funky debugging mode per far funzionare tutto, e AIUI è stato un vero e proprio hack. Probabilmente sarebbe più facile usare l'effettivo 'expect' stesso (eseguendo lo script' unbuffer') in un sottoprocesso; sì, rende l'implementazione più difficile, ma * ha * ottime possibilità di funzionare. Tranne con 'telnet.exe'; questo è un caso speciale (e extra-sucky). –