Add runtime flag to enable / disable execution shift deferring

[kyri-petrou]

Related issue: #8368

Context

The current behaviour of the ZIO runtime is to defer execution context shifting until an async operation takes place. There is a fair bit of debate around this behaviour, with valid arguments from both sides.

The good

Reducing execution context shifting can improve performance, especially in situations where we might be constantly shifting in-and-out of the execution context.

for {
  a <- ZIO.succeedBlocking(10)
  b = a + 10
  c <- ZIO.succeedBlocking(foo(b))
} yield c

In the case below, execution context shifting deferral works well because after the first line is evaluated, we continue execution in the blocking threadpool, which means that when the 2nd ZIO.succeedBlocking occurs, we won't be shifting back execution.

Another valid usecase is the one below, where execution context shifting allows us the same thread to execute the _ + 1 computation, before it reaches the end of the async boundary.

ZIO.foreachPar(1 to 100)(i => ZIO.succeedBlocking(foo(i)).map(_ + 1))

The bad

The most common use-case for shifting execution context is to perform blocking IO. In many cases, it is very likely to perform some/much CPU work to process the data obtained via IO. Since ZIO's blocking threadpool is unbounded, this means we could end up running CPU-bound workflows, which is.. very bad.

One example where this happens is in zio-query. What might not be immediately obvious in that code-block is that dataSources are almost definitely going to perform some IO, very often blocking IO. Following the execution of the datasource, we need to do some moderately expensive CPU such as creating HashMaps, fulfilling promises, etc.

PR changes

Currently, the only way to disable this behaviour is to override the default executor. However, this is just a side effect rather than the intended behaviour, and that might change at some point in the future.

Instead of taking sides on this argument, I think a better approach is to give users the option to control this behaviour explicitly via a RuntimeFlag (enabled by default to maintain the same behaviour as before). This also unlocks the potential for power users to enable/disable this behaviour in specific regions

PS: Please provide some feedback/alternatives for the naming of the flag. I think we can do better!

[ghostdogpr]

That flag sounds like it's going to defer the shifting even if you have an overriden executor. How about the inverse of this? Something like InstantShiftBack, off by default?

[jdegoes]

EagerShiftBack?

[jdegoes]

EagerBackshift?

[kyri-petrou]

Sorry this took me a while. Thanks for the recommendations, I updated the name of the flag to EagerShiftBack and disabled it by default