Support for actors expressed as async/await fuctions?

[mcginty]

Do we want?? Do we not want??

[strohel]

I presume this would mean: support actors whose handle() is an async fn, i.e. support for actors that run an async runtime in their thread.

It seems that Actix also somehow supports both sync and async actors through different implementations of its ActorContext trait. But Actix is clearly async-first.

Maybe a good time to consider this would be when we dog-food it. Otherwise I'd fear that async support could suffer from being a second-class citizen.

[mcginty]

Maybe another question worth asking is: how hard would it be to add async support after the initial release? Would it require major API changes?

[mbernat]

Correct me if I'm wrong but you can always run an async runtime inside a blocking function (such as inside actor's handle). There also exist tiny single-threaded executors that could make this quite viable.

This is obviously wasteful when you want to have many such actors, so I suppose the point of this issue is instead to run a single runtime that the async actors can run on top of?

Another consideration is that async frameworks typically use tasks as units of execution and take care of running them on their own thread pools (at least in case of multithreaded executors such as the work-stealing one in tokio), so it differs from the current one-thread-per-actor model. OTOH, many systems support both these options (dedicated threads where necessary, thread pool for simpler tasks), so it sounds like a net benefit.