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

[Ron Pressler]

> On 15 Mar 2023, at 13:59, Piotr Tarsa <piotr.tarsa at gmail.com> wrote:
> 
> 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.

The interruption mechanism in Java is not as user-friendly as we’d like it to be, but it offers all of the exact same capabilities, and it has offered them for over 25 years.
You have full control over where interruption can happen and over how and when to handle it when it does. In particular, resource cleanup on interruption works as it’s worked for decades.

> 
> 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.

That’s not how interrupting tasks in Java thread pools work. Take a look at Future.cancel, which has been widely used since 2004.

> 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.

We would like to offer a more user-friendly approach (that would be compatible with the current one), and I want to write post about it soonish, but it has nothing to do with the claims in the talk, which are simply false.

The main issue with the user-friendliness of interruption in Java is that the interrupt status can be reset, and that’s how cleanup (and uninterruptible regions) work. It would be better to have a status that cannot be reset, which would, indeed, require explicit uninterruptible regions. ScopedValues, which are supported by JIT intrinsics could be used as the underlying mechanism, which would then be more efficient than anything written outside the JDK, yet (hopefully) interact with the existing mechanism, so that code can be gradually migrated; approaches that require rewriting a lot of code don’t work. Note that this won’t make cancellation in Java more capable, just, hopefully, more user-friendly.

— Ron