Temporal coupling in Fibers and Fibers vs State Machines.

[Ron Pressler]

> it means you have to start caring at a function level "Is this running on a fiber pool or a regular pool”.  

I don’t think it does.

Every abstraction, pretty much by definition, hides some implementation details.
Java’s Map and List interfaces hide the cost of their operations; parallel streams
hide the number of processors, and threads hide the implementation of a scheduler.

If you’re writing a real-time application you might care a great deal about
the implementation of the scheduler — whether it handles priority inversion, whether
it works in a strict round-robin fashion etc.. Other times, you might care less.
But guess what? Reactive frameworks *also* hide the implementation of the scheduler.
IIRC, the Reactive Streams specification allows the scheduler to schedule all operations
onto a single thread, and make all operations blocking. So you need to care about
the implementation of the scheduler to the same extent, whether you’re writing 
synchronous or asynchronous code. Just as you pick a scheduler for your asynchronous
code, you can pick one for your synchronous code.

So I don’t see how threads make caring about scheduling more or less important. They
just offer a different way of expressing the same computation, a way that happens to
be more in line with how the Java platform — that’s largely organised around the thread
abstraction — is designed.

- Ron


On 19 February 2020 at 20:36:05, Thomas May (tmay at clearwateranalytics.com(mailto:tmay at clearwateranalytics.com)) wrote:

> > 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.
>  
> I believe the concerns are more that things like "CompletableFutures" are hard to intuitively
> compose correctly.
>  
> For example, think of a graph of Futures. Now imagine you want to conditionally traverse the graph
> based on node the values returned by each future and cancel the rest based on some condition.
>  
> With CompletableFutures and traditional threads, that's really difficult without introducing a lot of blocking
> on some thread. In fact, it's pretty much impossible using the composition methods available. You are
> forced to call `.join()`. This is isn't so bad with loom backed completable future but it is a killer for the standard FJP.
>  
> On the flip side, async/await syntax handles this sort of thing pretty much right out of the box. The awaits all
> allow the current thread to go do something else useful and, as a bonus, are pretty easy to read. The
> downside is the colored function problem.
>  
> I believe that is where the composition statement comes into play. Futures and promises are hard
> to compose correctly. They end up looking ugly and hard to read. Loom helps here, but ultimately,
> it means you have to start caring at a function level "Is this running on a fiber pool or a regular pool".
> If the answer is a regular pool, you run serious risks calling .join() if your code is also executing within the same pool.
>  
> Just my two cents.
>  
> I still like the loom approach simply because it eliminates the colored function problem without adding
> extra cognitive burden.
>  
> ________________________________
>  
> NOTICE: This e-mail message, together with any attachments, contains information of Clearwater Analytics and/or its affiliates that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately delete it. The information we provide is from sources Clearwater Analytics considers reliable, but Clearwater Analytics provides no warranties regarding the accuracy of the information. Further, nothing in the email should be construed as legal, financial, or tax advice, and any questions regarding the intended recipient's individual circumstances should be addressed to that recipient's lawyer and/or accountant.
>  
> Clearwater Analytics, 777 W. Main St, Boise, ID 83702
> If you prefer not to receive emails from Clearwater Analytics you may unsubscribe.