one of the ideas for when the days have 36 hours is a series of blog posts about a real world (so concurrency, interruption and so ) version of IO that prioritises code clarity over performance for ease of understanding
@julien-truffaut not as nice as having a code sketch, but do feel free to ask questions instead
I’m gonna get so much done
Just need to figure out how to slow earth’s rotation somehow
more abstractly,
IO is two free monads glued together with an interpreter that can sequence back and forth between them. Cont is itself a free monad for a coalgebra, while Free is obviously… uh, Free, and we instantiate it with a trivial algebra
the run loop today behaves radically different than this though
the naive run loop structure for the above type works, but is very slow and also sometimes quite tricky to get right (e.g. stack safety for
raiseError is hard with the above)
the more Enterprise Grade runloop structure requires a lot more groundwork :-)
I'm not sure exactly what you're looking for
I think the above is only confusing because
Cont is so bizarre
and
ContT is even more bizarre
it had an exceptionally cool bit where we defined
Task.liftIO
and it was literally just
flatMap on ContT
which I thought was clever
I would start looking at the runloop from these 3 points:
IOit's a tree that gets translated, and each node in the tree represent a fundamental concept (so you haveAsync,Delay,Attempt,Pure,FlatMap)- The runloop keeps a state, which is roughly
case class State(current: IO[Any], stack: List[Any => IO[Any]]. Each iteration pattern matches oncurrent, does some stuff, and keeps going by taking the next off the stack. - The (slightly simplified) type of
Asynciscase class Async(f: (Either[Throwable, A] => Unit) => Unit) extends IO[A]. The key point is thatAsyncdoes not introduce any asynchrony, it just wraps something that can already do asynchrony by itself. It's kinda funny in thatAsyncdoes most of the work for the "complex" stuff, but actually the only thing it does is passing a function to another function.
I can expand and unpack some of this if needed
@SystemFw I think I get all these points, what's not really clear to me is what to do in the run loop when the current IO is an Async
e.g. if it is the top level one
the only thing you can do with a function is to call it
so what you do is pass a callback to it
if it's the top one, the callback is passed to you, which is why
runAsync takes one
like all forms of CPS is a bit mind bendy
does that make any sense? (feel free to say no, maybe we can work through an example)
I am less sure what happens for the runSync
"you" meaning the runloop
actually it's quicker to just show you
val latch = new OneShotLatch
var ref: Either[Throwable, A] = null
ioa unsafeRunAsync { a =>
// Reading from `ref` happens after the block on `latch` is
// over, there's a happens-before relationship, so no extra
// synchronization is needed for visibility
ref = a
latch.releaseShared(1)
()
}
so in this case you have to rely on the native platform "waiting" mechanism
for the JVM, this is thread blocking
for JS, it's unsupported and you just throw UnsupportedOperationException
below those lines, you try and
acquire that latch, which blocks the thread until it gets released
at which point you return the contents of
ref
makes any sense?
but with thread blocking instead of fiber blocking