when using Kotlin Coroutines a `suspend` function ...

# arrow

[abendt]

when using Kotlin Coroutines a suspend function should not use blocking operations. How is this in the context of arrow-fx and IO ? Is this a requirement here too or is suspend only used as a marker to tag functions for having sideeffects?

[aballano]

I'd say the second one, as you wrap your suspend functions with IO, you are able to easily switch threads if that's something you need

[aballano]

not sure why is it like this in the kotlin coroutines tho, do you have more info about that?

[abendt]

as far as i understand multiple coroutines may be executed by a single thread, using a blocking operation in one coroutine would prevent this thread from executing the other coroutines. therefor one should use the non blocking suspending alternatives (e.g. delay instead of sleep)

[aballano]

ahh i see, thank you 🙂

[raulraja]

You should try to avoid blocking operations in general but if you must you should use a dispatcher that is able to allocate more threads to fulfill them. The kind of dispatcher and whether the default dispatcher works is gonna depend on the kind of blocking op you are doing.

[raulraja]

The default dispatcher uses work stealing and favors cpu bound ops over I/O blocking ops.

[abendt]

thanks. is that the correct way to use a custom dispatcher?

IO.effect(IO.dispatchers().io()) {
  blockingFunctionHere()
}

[aballano]

afaik yes, you can even drop the effect and just call it like a constructor

IO(IO.dispatchers().io()) {
  blockingFunctionHere()
}

[raulraja]

You can also do:

IO.fx {
  continueOn(IO.dispatchers().io())
  val result = !effect { blockingEffectHere() }
  continueOn(UIDispatcher)
  !effect { showResult(result) }
  continueOn(IO.dispatchers().default())
  !resumeBizAsUsualInForkJoinPool()    
}

[raulraja]

while reading this gives the impression things could scape async because it looks like imperative code it all happens in the IO fx managed block and each one of those commands end up turning into flatMap chains underneath

[raulraja]

https://arrow-kt.io/docs/fx/async/#dispatchers-and-contexts

[raulraja]

You can also use fibers if you want finer control of when to fork/join to manually start and bind your processes. All other operations also use fibers underneath when required. This just gives you a more low level DSL. https://arrow-kt.io/docs/fx/async/#fibers like async/await

[raulraja]

And if you need to get lower the Fx library includes concurrency primitives like Semaphore IORef and others that allow you to use concurrent/async synchronized mutable variables.

[raulraja]

but that are still pure in the context of IO

[abendt]

thanks @raulraja @aballano!