Volevo scrivere un programma che scrive su più file contemporaneamente; pensato che sarà possibile con un thread usando la modalità non bloccante. Ma FileChannel non supporta la modalità non bloccante. Qualcuno sa perché?Perché FileChannel in Java non è non bloccante?
UNIX non supporta l'I/O non bloccante per i file, vedere Non-blocking I/O with regular files. Poiché Java dovrebbe (almeno provare a) fornire lo stesso comportamento su tutte le piattaforme, lo FileChannel non implementa SelectableChannel.
Tuttavia Java 7 includerà una nuova AsynchronousFileChannel classe che supporta asincrona di file I/O, che è un meccanismo diverso per I/O non bloccante. Una delle sue implementazioni WindowsAsynchronousFileChannelImpl beneficia dell'API I/O non bloccante su Windows (vedere Asynchronous I/O in Windows).
Nel frattempo, è possibile utilizzare più thread per ottenere lo stesso effetto. Ma questo è già implementato in SimpleAsynchronousFileChannelImpl, che è portatile su tutti i sistemi operativi.
In generale, solo socket e pipe supportano realmente l'I/O non bloccante tramite il meccanismo select().
@Trying commenti così:
"AsynchronousFileChannel supporta I asincrona O piuttosto che non bloccante /"
Secondo me, I/O asincrono (usando per esempio Future o un CompletionHandler) è una forma di I/O non bloccante.
read(...) sul canale.Future.isDone() per evitare il blocco successivo.(E, naturalmente, di I/O con un Selector può essere asincrono troppo ... a seconda di come si utilizza l'API.)
Al contrario, se si legge su un FileChannel e non c'è dati attualmente disponibili, il thread blocca ... (in genere) finché i dati non diventano disponibili.
In poche parole, la maggior parte dei sistemi operativi non considera i file normali come qualcosa che può bloccare, pertanto non consente di impostarli esplicitamente su uno stato non bloccante.
I/O file possono essere bloccati solo perché sono considerati non bloccanti? Che cosa vuoi dire con questo? Nella programmazione, ogni operazione sta bloccando. – Val
@Val Concordo sul fatto che la formulazione non sia la migliore qui. Nella programmazione, non tutte le operazioni si bloccano (nel senso che mette il processo o il thread in uno stato di blocco). Quello che intendo è che per un file normale, le API a livello di sistema operativo presuppongono che read()/write()/open() e altre chiamate su un file normale non siano bloccanti, sebbene si tratti di una falsa ipotesi. Le API standard/standard OS non possono modificare l'handle in un file da blocking a non-blocking. (che è qualcosa che puoi fare con prese e manici per tubi). – nos
@nos Le API a livello di sistema operativo presumono che 'read()/write()/open()' e altre chiamate siano * bloccanti *. Non chiaro di cosa stai parlando. – EJP
+1. asynchronousFileChannel supporta l'I/O asincrono piuttosto che il blocco. si prega di controllare. Grazie. – Trying
@Trying - Ho indirizzato il tuo commento. (Non sono completamente d'accordo ...) –
Non vedo nulla in ['WindowsAsynchronousFileChannelImpl'] (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40 -b43/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java) che "beneficia dell'API non bloccante su Windows". Si prega di chiarire o correggere. L'I/O asincrono è molto più simile a un I/O di blocco eseguito su un thread separato rispetto a un I/O non bloccante. – EJP