Why not Dispatcher? about feral HOT 4 CLOSED

Thanks for opening the issue! It's a good question, and I think we can revisit this design choice.

How is the Dispatcher's run different than just using the unsafe global provided?

Here are three advantages of using Dispatcher#unsafeRun over IO#unsafeRun*:

1. You can have a dispatcher in a generic effect F[_] i.e. Dispatcher[F]
2. A dispatcher has a scope / lifecycle i.e. it is a Resource[F, Dispatcher[F]]. You can be confident that tasks are not being leaked after the dispatcher has been closed.
3. A Dispatcher is backed by an already running "warm" fiber. Meanwhile, IO#unsafeRun* has to do extra set-up every time it is used, e.g. registering fatal error handlers.

Should feral replace its unsafeRunSync with a Dispatcher per the advice above?

Yes and no :) point (3) above is a good motivation to create a dispatcher when the lambda starts and use it to handle all incoming requests.

The question is, how will we get that dispatcher? Since the only way to create a Dispatcher is inside of an effectful resource, but without the dispatcher we can't run any effects.

So, we will still need IO#unsafeRun*. We can use this exactly once to obtain a dispatcher during the setup process, that we can then use for all subsequent requests.

Does that answer your question? Thanks, and PRs welcome for this :)

from feral.

Shout out @kamilkloch :)

from feral.

So are you suggesting that with both Feral and my work, we should bootstrap a Dispatcher like a resource for the lifetime of the lambda, and then continually use that Dispatcher for the times when we need to be unsafe?

from feral.

Yes, exactly. It seems to me that an application should never have to call IO.unsafeRun* more than once: instead, it can use that one call to setup a Dispatcher, and use that for all subsequent unsafe calls.

from feral.