📝Is blocking I/O worth coloring?

tags

Function color

What Color is Your Function? argues that having threads is enough to avoid function coloring.

True, you can technically avoid coloring if threads can block on I/O. However, blocking system calls have quite a few caveats around them, so that you might want to avoid them in certain cases and they are worth calling out / distinguishing from other functions.

Parking the whole OS thread in syscall is also more costly, which is the main reason why some languages that already have threads still implement async-await (e.g., Rust, C#, Kotlin).

Counterarguments

• How blocking syscalls are different from CPU-heavy functions? Both may “block” the thread for quite a bit.
  • CPU-heavy functions are usually more predictable.
• Blocking I/O may also happen at other places besides syscalls. For example, page miss may trigger reading swapped out page from disk.
• In case of Go, I/O functions don’t have color even though they block the current goroutine. So maybe the distinction is not that important after all. Haskell is similar, although all potentially blocking functions are under IO monad.
• Coroutines also don’t normally need special keywords.

Answer

Probably not in the general case.

Coloring creates a strong distinction and adds arbitrary rules where I/O is acceptable or not.

In some cases, it’s still worth calling out and explicitly allowing/forbidding arbitrary I/O at certain sections and that’s where § Effect systems can be helpful.