In the wonderful book „Elixir in Action“, @sasajuric writes that
I/O operations are internally delegated to separate threads, or a kernel-poll service of the underlying OS is used if available. This means any process that waits for an I/O operation to finish won’t block the execution of other processes.
I’m wondering the following:
- What kind of “separate thread” is meant here. Does he mean a separate OS thread, so one that lives outside of the BEAM?
- If yes, how does the BEAM know when the thread is finished?
- And how does it restart the I/O thread if it crashes?
1 Like
These are called “dirty IO schedulers” (previously, async threads), and you can find a bit about them here. These threads are running inside beam, and my guess (but I’m not completely sure) is that they are constantly running i.e. it’s a pool of threads serving all processes in the beam. These threads shouldn’t crash. They are not processes, and they are not running our custom Elixir or Erlang code. Instead they only perform the requested IO operation, and return the result to the caller process.
The consequence for beam users is that a blocking IO operation will block the process and nothing else.
6 Likes