2015-07-23 14 views
5

Sto creando un bridge veloce tra due programmi separati.È Java FileInputStream Locking File per la scrittura

Un programma scrive su un file, mentre il mio programma legge contemporaneamente da esso.

Sembra che non appena chiamo la prima lettura la scrittura sia completamente bloccata.

Perché si verifica questo e qual è la soluzione?

// Create Named Pipe 
Runtime.getRuntime.exec("mkfifo /tmp/mypipe") 

val stream = new FileInputStream("/tmp/mypipe") 

val in = new BufferedReader(new InputStreamReader(stream)) 

// File opened for reading. No blocking at this point. 

while (true) { 

    println(in.readLine()) 

    // File read. Now blocking. 

} 

Aggiornamento:

Questo file è in realtà una named pipe creata con mkfifo /tmp/mypipe. Ho provato a utilizzare questo con un normale File e ha funzionato bene - tutti i dati visualizzati.

Sto usando una named pipe perché non voglio l'overhead del disco IO.

+0

Puoi mostrare anche l'altro programma? – Vlad

+1

@Vlad non ho fonte e non è pubblico. Tutto ciò che fa è scrivere non leggere. Il ciclo while e la mancanza di una chiusura corretta sono semplici standard. – BAR

risposta

6

Se dovessi scommettere, direi che si tratta di un problema di buffering.

Inizialmente pensavo che lo BufferedReader potesse tentare di riempire l'intero buffer, ma sembra che sia felice fintanto che legge qualcosa. Vedi il metodo fill().

Se si utilizza readLine(), c'è anche la domanda se l'input che si ottiene contenga newline.

L'altra cosa che potrebbe accadere, a seconda della quantità di output prodotta dal programma sorgente, è legata al buffering delle pipe. this answer aiuto? È anche possibile provare a terminare il programma sorgente (ad esempio ^C o simile) e quindi verificare se il programma di destinazione stampa nulla.

This pagina suggerisce che il buffer potrebbe essere un problema:

Tuttavia, se si utilizza una scrittura buffer, il buffer non viene reso disponibile al lettore finché il buffer viene svuotato. Questo arrossamento si verifica quando vengono scritti nel buffer più della dimensione massima del buffer (BUFSIZ impostato in stdio.h) o quando la pipe viene chiusa dal writer.

+0

Ho provato a controllare la lunghezza del file dei dati letti prima e dopo aver inserito un 'Thread.sleep (5000)' tra la creazione 'BufferedReader' e prima letto - le lunghezze dei file rispettivi erano 11.498 byte e 15.521 byte con 99 e 131 linee . Quindi la risposta collegata non sembra essere quella. – BAR

+0

Usando '$ cat/dev/urandom | hexdump -C>/tmp/mypipe' come comando di scrittura, e il tuo programma Scala come lettore, lo streaming è indefinito. C'è qualcosa nel tuo programma sorgente che, ad es. vuole qualche input da parte dell'utente, o qualcosa del genere? – Vlad

+0

Nessun input o richiesta da parte dell'utente - solo un tunnel a senso unico. Proverò a usare 'cat'. – BAR

Problemi correlati