Async `recv` Functions?

[zicklag]

I'm curious, would it make sense to have Actor::recv an async fn? That way you could use futures inside of them with .await and avoid having to ctx.run() and block_on.

The problem I would see with it would be that you wouldn't want to do blocking operations in a recv implementation because it would stall the executor. Tokio handles those situations with a spawn_blocking(|| do_blocking_stuff()) pattern. That might be something to consider.

Anyway, I just wanted to open up the discussion and see what thoughts were on it. I'm really liking the look of Riker so far.

[aav]

As far as I know, rust currently does not support async in traits. Maybe, it makes sense to create AsyncActor that returns Future from recv (and other callbacks).

[zicklag]

The async_trait crate is one way to handle that. Also the blocking crate can handle spawning blocking operations.

[aav]

Meanwhile, I created a small prototype (based on the _asynctrait). I will take a closer look at what I've got and create a branch, so it could be reviewed.

#[async_trait]
impl Actor for MyActor {
    type Msg = MyMessage;

    async fn recv_async(&mut self, _ctx: &Context<Self::Msg>, _msg: Self::Msg, _sender: Sender) {
        println!("*** async message before");
        let _ = Delay::new(Duration::from_millis(1000)).await;
        println!("*** async message after delay");
    }
}

[aav]

Here is the proof of concept: https://github.com/aav/riker/tree/async_recv

There are two alternatives ahead

• change all callbacks to async, including Receive, ActorFactory*, and, probably, some other parts of API. This is a no-compromise solution, but it will introduce breaking changes and add async_trait as a dependency.
• keep both recv and recv_async functions in the Actor trait. In this case, both of them will require default implementation. Internally, we will be async, but the default implementation of recv_async will call the usual recv.
• maintain parallel versions of Actor / AsyncActor traits, perhaps, even placing the second one under a feature flag.

I personally prefer the first approach, because I believe async is more idiomatic here. And, once, async trait functions will get supported, we will be able to get rid of extra dependency. For consumers who don't need async, the extra trouble will be minimal.

@leenozara what do you think?

[igalic]

For consumers who don't need async, the extra trouble will be minimal.

how so?

[aav]

For consumers who don't need async, the extra trouble will be minimal.

how so?

for those who don't care if recv is async, the extra steps (compared to how it is now) will be:

• add async_trait dependency
• mark Actor trait implementation with #[async_trait]
• declare recv as async fn recv

that's not much, as I think

[mankinskin]

@aav would you mind rebasing your async_recv branch on the current master and maybe make a PR? I think with this patch we could actually get somewhere with this.

I would also like to make the other lifetime methods in actor (pre_start, post_stop, etc) async.