The Great Concurrency Smackdown: ZIO versus JDK by John A. De Goes

[Piotr Tarsa]

Hi Ron and others,

I've just subscribed, so I will post a reduced email (without quoting
the entire discussion).

While I agree with most points made by Ron and particularly agree that
John didn't make solid enough effort to understand Loom, there is at
least one area where I think that ZIO seems to have an advantage over
Java threads (virtual or not). It's the interruption model.

Quoting Ron:

> 2. Interruption is as reliable as anything that can be offered in either Java or
> Scala. The mechanism could be made more friendly, but I don't think that's what
> he's talking about. It may not be as reliable as what Erlang can offer thanks
> to its special restrictions on the language.

I don't know Erlang (well, I've looked at some tutorial briefly and
that's it) so I can't comment on Erlang, but I think I can make
educated guesses about Java threads' interruption and ZIO fiber
interruption models.

What ZIO adds are uninterruptible regions, where interruption signal
is delayed until the end of interruptible region. That is used to
prevent interrupting resources cleanup, so it possibly greatly helps
avoiding resource leaks. The small downside is that interruption isn't
immediate then, but in Java you can eat the InterruptedException and
delay (possibly forever) interruption too. In the end, uninterruptible
regions are (in my opinion) significant advantage of ZIO fiber
scheduling over raw Java threads (whether virtual or platform, as both
lack uninterruptible regions). I think that with broader usage of
virtual threads, the prevention of interruption of resource cleanup
will play more and more significant role.

Right now interruption in Java is probably not used much, so Java
programmers don't have much experience with it anyway (especially in
problematic cases). Today (in pre-Loom world) what everyone uses is
thread pooling where we submit series of tasks that are multiplexed on
threads (more or less) randomly selected from thread pool. In such
scenarios interruption is not a good mechanism as it's prone to race
condition which would lead to interrupting the wrong task. In ZIO it's
different as the interruption management is built into ZIO scheduler
and everything must go through ZIO scheduler, so ZIO scheduler is able
to efficiently prevent interrupting the wrong task (or rather ZIO
fiber as it's the unit of sequential computation that is interrupted
in ZIO). In Loom thread pooling is discouraged and with separate
virtual thread per task we can reliably interrupt the correct task,
but Java threads API still lacks support for uninterruptible regions.

While it probably could be possible to implement uninterruptible
regions over Java threads, it would be probably far from optimal. In
ZIO fiber interruption is built into ZIO scheduler (from
implementation point) and ZIO fibers API (from user visible API
point), so it's relatively efficient and universal out-of-the-box.
With external libraries implementing uninterruptible regions, whether
in Java or Scala, whether hypothetical extra ZIO library or not, the
downside would be that it would be less efficient, but more
importantly it would require some discipline and ecosystem
compatibility, so that everyone would interrupt things through the
external library, because otherwise the whole mechanism of
uninterruptible regions would be compromised and effectively useless.

In summary, I think Java thread API needs to offer uninterruptible
regions out-of-the-box and that need will be stronger as interruption
will be used more.

I may be wrong though :)

Regards,
Piotr