 
  		        dhmitchell
Kotlin Coroutine Confidence: asynchronous read file
In “gallery/v14/src/main/kotlin/com/example/gallery/GetImageFromFile.kt”
- won’t the .usealways callchannel.close()on exit? if so, why do you needinvokeOnCancellation? or does cancellation somehow avoid thefinallyin theuse?
- if I wanted to iterate through the file line by line, I presume I’d call readlinerather thanreadand otherwise it’s roughly the same?
Marked As Solved
 
		        sam-cooper
Yes, since the use() block wraps the entire call to suspendCancellableCoroutine(), it will always close the AsynchronousFileChannel when suspendCancellableCoroutine() exits for any reason. The problem is that without that invokeOnCancellation() block, suspendCancellableCoroutine() will not exit—at least, not until we’ve finished reading the entire file.
What we’re trying to do by adding invokeOnCancellation() is to ensure that we can stop the file operation before it finishes. When the coroutine is cancelled, Kotlin executes the invokeOnCancellation() block. Calling channel.close() inside the block is how we interrupt the ongoing file operation and cause it to end early.
That means there are two different ways the file can be closed:
- The read()operation ends on its own, either because it reached the end of the file or because it ran into an I/O error. The suspension point resumes, and the coroutine exits theuse()block, closing the channel in the process.
- The user cancels the coroutine before read()is done. This triggersinvokeOnCancellation(), which in turn callschannel.close(). This fires theread()operation’sfailed()callback, allowing the coroutine to resume from its suspended state without waiting for the rest of the data. Again, it exits theuse()block, but the file channel is already closed, so that’s a no-op.
I’ll see what I can do to make all this clearer in the book! Although it’s not something you’re likely to have to deal with often, I’d like to make sure it’s clear.
As for the second question, that’s a little trickier. The AsynchronousFileChannel just deals with raw byte data, and it doesn’t have any methods for working with text or line separators. Unfortunately that means there’s no readLine() function. You could write one of your own, but you’d need to include logic to buffer the data in chunks, inspect it for line separators, and so on.
In a real application, it’s likely that the more complete feature set of the java.io libraries will outweigh any asynchronous advantage from using java.nio. If I needed to read lines from a text file, I’d probably just use a good old fashioned Reader, and accept the minor cost of a blocked IO thread. In the book, I’m not intending to advocate for using AsynchronousFileChannel all over the place—it’s just meant as a handy example of a simple (ish) operation that we can use to illustrate asynchronous callbacks. Perhaps I’ll add a quick note to that effect in the text, too.
Phew! With any luck, I’ll find a way to say all this in the book using slightly fewer words. Thanks for asking these questions—they all help me to make the explanations in the book clearer.
Popular Pragmatic Bookshelf topics
                         
                      
                       
           
           
           
           
           
           
           
           
           
          Other popular topics
                         
                      
                       
           
           
           
           
           
           
           
           
           
          Categories:
Sub Categories:
Popular Portals
- /elixir
- /rust
- /ruby
- /wasm
- /erlang
- /phoenix
- /keyboards
- /python
- /rails
- /js
- /security
- /go
- /swift
- /vim
- /clojure
- /emacs
- /haskell
- /java
- /svelte
- /onivim
- /typescript
- /kotlin
- /crystal
- /c-plus-plus
- /tailwind
- /react
- /gleam
- /ocaml
- /elm
- /flutter
- /vscode
- /ash
- /opensuse
- /html
- /centos
- /php
- /deepseek
- /zig
- /scala
- /lisp
- /sublime-text
- /textmate
- /react-native
- /nixos
- /debian
- /agda
- /kubuntu
- /arch-linux
- /django
- /revery
- /ubuntu
- /deno
- /spring
- /nodejs
- /manjaro
- /diversity
- /lua
- /julia
- /c
- /slackware
 
    





