Temporal coupling in Fibers and Fibers vs State Machines.

[Alex Otenko]

The problem with all forms of async is that they are bolted on to the
language.

For loop is great. Lexical scopes are there to control visibility and
lifespan of variables. Java language guarantees which statements are
reachable and which are not and when.

Concurrency issues are not limited to JMM. It is a general problem of
knowing what gets executed when, and which of the ordering is intentional,
and which is accidental consequence of the implementation (how do you
refactor in order-preserving, bug-compatible way). Yes, when using threads
these problems reduce pretty much to the cases JMM calls out. With reactive
and futures the stretches of code where program order applies, are much
much shorter.

The biggest problem with futures and reactive is the absence of those basic
guarantees that the language provides - it becomes an implementation detail.

Even such simple things as "will this piece of code be executed" are no
longer something the language semantics can guarantee - if the future is
not completed because of a bug in the code, you have code behaving like
non-termination. Same with reactive. "Will this code be executed once and
only once" is no longer something the language semantics can guarantee. If
the implementation of a Publisher is broken, there is no defense, you are
going to receive out of order events, arbitrary number of times.

Not so with for loops. There are easily comprehensible semantics of what is
executed when, how to break the loop, what happens to errors.


Alex

On Wed, 19 Feb 2020, 19:43 Dávid Karnok, <akarnokd at gmail.com> wrote:

> Rafael's concerns are mostly related how the functional and declarative
> nature of the reactive libraries are difficult to learn for some people.
> Yet, these people happily code in SQL and use Java Streams. Maybe it's time
> to go back to reading database files with InputStream and use for loops as
> well.
>
> Martin's concerns are, if by composition he means what I think he means, if
> you could set up pieces of computation and functionality and combine them
> into larger components. If so, these components can have state and those
> state could change in response to stimuli from other components. Reactive
> is one of such approach that has individual pieces - operators chained up
> on a dataflow have internal state tracking when and how their peers can
> send data and commands to each other. Loom's, and Kotlin's Coroutines
> instead say you compose via the source code itself, by writing larger and
> larger methods encompassing a lot of imperative operations. If you have
> such a method, but for some uses need some retry code, you may be out of
> luck and have to code yet another set of methods to include that
> functionality.
>
> Vaughn's concerns are that there aren't many helping hands with Fibers and
> concurrency. In fact, you have to consider the Java Memory Model again the
> moment two routines in separate fibers have to communicate: blocking
> structures, atomics, locks and their effects on visibility. In reactive,
> from an user's perspective, you don't have to worry about most of these as
> the libraries can hide many of the intricacies of the JMM and provide you
> with an API and callback surface. Want to create an item and hand it over
> to another thread for processing? There are operators for that and you have
> only to specify how to create the item, what thread it should end up and
> what processing there should be for it. Want to generate many items?
> Replace the front of the flow and the rest will still be the same.
>
> Also note that Loom's sales pitch has shifted over the years. It started as
> the solution that will outperform reactive and having users code in easy to
> understand imperative fashion as the JVM will do the heavy lifting behind
> the scenes. However, we have pointed out that a) suspension is more costly
> and may dominate the overheads, b) composition (see above) is limited so
> people, individually and over and over, may end up with DIY solutions and
> c) you have to make sure locks/blocking happen in a virtual thread for
> which you may have to inject virtual thread-based executors all over the
> place.
>
> Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2020. febr. 19.,
> Sze, 19:48):
>
> >
> > Hi.
> >
> > I don’t think I really understand what the concerns are, and believe they
> > might
> > be tied to a misunderstanding of Loom’s goals and design.
> >
> > Anyone who has concerns is welcome to explain them here, without
> > character-count limits.
> >
> > Ron
> >
> >
> >
> > On 19 February 2020 at 18:37:53, Rahul Khandelwal (rahulnewai at gmail.com
> > (mailto:rahulnewai at gmail.com)) wrote:
> >
> > > Hi All,
> > >
> > > I have been following Project Loom for quite some time now and I find
> it
> > > really exciting.
> > > This is my first post in the mailing list.
> > >
> > > I went through the following twitter discussion -
> > > https://twitter.com/rafaelcodes/status/1176229314112741377
> > > However I could not understand the final gist/conclusion of the
> > discussion.
> > >
> > > 1. Here In the discussion Martin Thompson had the view that Fibers
> don't
> > > compose and cannot escape temporal coupling.
> > > He also advocated about the use of explicit state machines instead of
> > > Fibers.
> > > https://twitter.com/mjpt777/status/1176231250308325376
> > >
> > > 2. Vaughn Vernon had opinions around the Java memory model and the
> > > complexity of the effects of predictive execution.
> > > https://twitter.com/VaughnVernon/status/1176299015849136128
> > >
> > >
> > > Could someone explain what were the concerns and suggestions they
> > expressed
> > > and how Fibers handle said concerns.
> > >
> > > It would be great if someone could suggest some resources to better
> > > understand above twitter discussion.
> > >
> > >
> > > Thanks,
> > > Rahul
> >
> >
>
> --
> Best regards,
> David Karnok
>