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.

[strohel]

Correct me if I'm wrong but you can always run an async runtime inside a blocking function (such as inside actor's handle).

Yeah definitely! They can crate a future and call some small_executor.block_on(future) in their handle(). That serves quite some use-cases. There are some little caveats like that the actor won't responsive (i.e. w.r.t. shutting down) while this happens (already the case in our current blocking approach). And most crucially any extra async tasks spawned would stop when handle() returns.

But the highest leverage would be if Actor::handle() could be async itself. Then we wouldn't have to do things like "time-out socket read after 100ms and yield briefly to the actor system to be able to react to shutdown" etc.

And in fact, it may not be that hard, as flume, the library that provides inter-thread channels for actor, already supports async: https://docs.rs/flume/latest/flume/async/index.html

We could introduce some AsyncActor trait whose methods would be async, and use a different main loop for it (basically starting some thread-local executor and feeding it the main future that listens to actor's channels).