Blocking or computationally intensive operations

[sergefdrv]

How Libretto would interpolate such Scala code into a Libretto program, that is blocking on IO or otherwise long-running? I suppose Libretto runtime executes a number of components in parallel on a thread pool. Is there a way to mark some components so that they get run in dedicated threads?

[MateuszKowalewski]

I think something like that would be against the core idea here.

The interface which allows using "opaque" Scala functions is meant to be used only at the input and output layers of a Libretto program, as I get it. The whole point is to not use such "opaque" functions in the first place inside your Libretto program as these functions don't compose (in a concurrent by design setting)—and you can't take advantage of Libretto's linearity when using raw Scala functions, which would make the whole concept moot.

But don't take my reasoning as authoritative. I'm just a bystander… 😄

Only @TomasMikula may answer this definitively.

Off-Topic note: You've started a really interesting looking project! I may come there as I'm also interested (form the engineering standpoint) in simplifying state synchronization in concurrent systems. The whole HTTP madness needs to come to an end finally! REST is the maximally biggest nonsense when all you want is building distributed apps…

[sergefdrv]

Imagine that in the middle of your program you naturally needs to query a database. Would you like pushing that query out of the stop where you actually need it to the input/output layer of your Libretto/Scaletto program? That would require some awkward wiring.

I think Libretto/Scaletto could still ensure linearity for such alien components, as long as they obey certain requirements. In particular, special care should be taken in case of long-running computations in order not to obstruct the rest of the concurrent program.

It is good to start with and study the most restrictive setting, but then one often needs to carefully relax some restrictions in order to make things practical. For example, structured programming was a profoundly great idea, but initially struggled to find adoption until certain limited forms of the goto statement were allowed, such as return, break, continue etc.

[MateuszKowalewski]

I guess I was wrong here. Libretto already seems to be able to do what you want.

I should have looked more carefully before writing something...

https://github.com/TomasMikula/libretto/blob/main/examples/src/main/scala/libretto/examples/libraryOfAlexandria/ConnectorModuleImpl.scala#L58

I guess I was confused because I was looking into streams lately. But now I've remembered the above example.

But how the runtime handles this in detail I don't know. Likely like you say as this seems to be the usual approach. I guess the truth is in the code. 😉

OTOH, in this library example, the blocking task is also kind of "on the edge", as it's a fetch operation which "pipes" data into the Libretto program. But no awkward wiring is needed as Libretto is (at least in my understanding) all about expressing and building such "wirings" in a simple declarative way. It's than up to the implementation (and its runtime) to sort out how exactly wire up and run the components.

The long term idea seems to be anyway to compile Libretto down to specialized and optimized code so no runtime (interpretation) would be needed.

[Again, please take everything I say with a middle sized grain of salt as I'm also just exploring this thingy here.]

[sergefdrv]

Apparently, you're right. This seems to be the most relevant definition, unless you can point to somewhere more relevant.

[MateuszKowalewski]

To answer the question regarding a dedicated thread pool:

https://github.com/TomasMikula/libretto/blob/main/core/src/main/scala/libretto/scaletto/impl/futurebased/ExecutionImpl.scala#L199

https://github.com/TomasMikula/libretto/blob/main/core/src/main/scala/libretto/scaletto/impl/futurebased/ExecutionImpl.scala#L207

When you trace back blockingEC you'll find a dedicated "ExecutionContext" (Scala speak for more or less a ThreadPool resource) of a kind that can handle potentially indefinitely blocking tasks:

https://github.com/TomasMikula/libretto/blob/main/core/src/main/scala/libretto/scaletto/impl/futurebased/FutureExecutor.scala#L19

https://github.com/TomasMikula/libretto/blob/main/core/src/main/scala/libretto/scaletto/impl/futurebased/FutureExecutor.scala#L72

[sergefdrv]

Great! That answer my question. Thanks! 🙏

[TomasMikula]

I'm glad that you have worked out the answer!

You correctly noted that blocking operations regard only embedded Scala code, not core Libretto code. More generally, the term "blocking" makes sense only in the world of threads, as it refers to blocking a thread. As there are no threads in Libretto, the term "blocking" does not even make sense in core Libretto.

Nevertheless, Scaletto permits to wrap Scala values and (pure) Scala functions on them, as well as Scala resources and (effectful) functions on them. As these Scala functions run inside threads, it becomes desirable to be able to mark some of them as blocking.

So much for the reasoning behind having the "blocking" marker for Scala functions.

However, you have also touched the problem of whether to perform I/O anywhere inside the program or only at the boundary. I will later write my thoughts on that (probably in a different thread as it is unrelated to blocking).

[TomasMikula]

@sergefdrv @MateuszKowalewski My thoughts on pushing I/O out of the program, with (imagined) application to composing microservices, are in #96.

[sergefdrv]

@MateuszKowalewski Libretto is on my list of things to explore, and I'm thinking of applying some ideas from it to help solve distributed systems difficulties. Though, I plan to get Replica_IO first implemented in Rust. You're more than welcome to participate if what's written in the readme resonates with you! I invite you to start by joining the Discord chat.

[MateuszKowalewski]

I've found your list before. This made me especially curious! 😄