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

[Piotr Tarsa]

Hi again,

I've made small mistakes already:

> What ZIO adds are uninterruptible regions, where interruption signal
is delayed until the end of interruptible region.

That should read: ... until the end of uninterruptible region.

Thanks

śr., 15 mar 2023 o 14:59 Piotr Tarsa <piotr.tarsa at gmail.com> napisał(a):
>
> 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