Return value to original caller, sleep to imitate workload

[TmLev]

Hey there!

I'm trying out Stakker to see whether it'll fit with a hybrid cloud simulator of mine.

Two things I'd like to implement are:

• In a scenario where one actor (service provider) calls another (external provider), how can the recipient return value without having references to or knowing about the original sender?
• Virtual machines have to execute some jobs, which can be imitated as sleeping for some time – what should I use in such case?

Thanks!

[uazu]

To return a value to the caller, pass a Ret instance in the call. Then the called method can pass back a value using the ret! macro on that Ret instance. This could be later on, e.g. it could store the Ret somewhere and return a value later when some calculation has completed (or whatever). There is a brief example in the docs -- in particular the call to query: let ret = ret_some_to!([cx], recv_state(self.count) as (bool)); call!([self.light], query(ret));. The ret_to! and ret_some_to! macros do the job of creating a Ret to return the data to the caller. They can either return to a local method of the caller (may be private) or to inline code. So the Ret is like an asynchronous callback, like you'd use closures for callbacks in normal synchronous Rust code. See the docs for more info.

You can set up timers or timeouts using after! or at! macros, and you can get current instant using cx.now(). There is an example of after! in the same tutorial example. The action performed when the timer completes can be a call to a method in this actor or in another actor, or it could be inline code.

Note that if you wish to run in virtual time, then the time used by after! and so on is virtual time, not real time. If you run with a virtual time main loop (illustrated just below the example in the docs), then execution will proceed exactly as for running in real time (i.e. outputs and calculations will be the same), except that instead of actually sleeping it will just skip time forward. So the simulation will run faster.

Have a look at the docs for the things I mentioned, and if it isn't clear ask further.

[TmLev]

After spending some time with the docs and sources, I think I got it. Thanks!
I don't think there is a way for a blocking wait, is there?

[uazu]

What do you need to block on? It's your app so you can block if you really want to, but just bear in mind that it blocks the entire thread and stops all the actors from processing events. If you mean you want to write sleep inline in the code, then no, that's not supported. Actor methods shouldn't block. That would need something like actor coroutines that use generators or async/await to yield back to the event loop whilst it sleeps. I'm gradually adding some async/await support to Stakker, but it won't have access to actor state yet, because there is no way to do statically-checked borrowing within poll (as yet), and I'd prefer not to use dynamic checks. So I don't have anything you can use to write sequential-style actor code just yet.

[TmLev]

For instance, actor A calls actor B and wants to receive some value back:

impl A {
    fn send(&self, cx: CX![]) {
        let ret = ret_some_to!([cx], recv() as (String));
        call!([self.actor_b], query(ret));
    }

    fn recv(&self, cx: CX![], msg: String) {
        println!("{}", msg);
    }
}

impl B {
    fn query(&self, cx: CX![], ret: Ret<String>) {
        ret!([ret], "Hello".to_string());
    }
}

Sometimes, A has nothing to do other than to wait for B to return a value. So, ideally, code could look like so:

impl A {
    fn act(&self, cx: CX![]) {
        let ret = ret_some_to!([cx]);
        let handle = call!([self.actor_b], query(ret));
        let msg = handle.wait();
        println!("{}", msg);
    }
}

impl B {
    fn query(&self, cx: CX![], ret: Ret<String>) {
        ret!([ret], "Hello".to_string());
    }
}

It really resembles async / await, for that matter.

[uazu]

Okay, but that's not the actor way. As an actor, you have state, and you have incoming events. When an event comes in, you consider your state and decide how to react to that event, and once you have reacted to it, you are done with that event and can return control to the main loop. That's the actor way of thinking about things. Taking the actor approach allows you to handle really complex problems quite easily, one event at a time, one decision at a time.

What you're talking about is something like async/await, which is backwards compared to actors. It encourages sequential thinking. But what happens if there is another event that comes in during that handle.wait() call that changes your view on what you need to do with that return value? That messes up the nice sequential logic. Also in the actor model there's nothing to stop you sending requests to 3 other actors at the same time, if that's what you need to do, and deal with the replies as they come back, or fail, as that happens, maybe asynchronously with other operations going on. But in a sequential model like async/await it's hard to handle that case as flexibly.

As it is, Stakker is a pure actor system in the sense that the sequential "wait for a future" kind of code is not supported yet. However, at some point I will support using async/await as a layer above the pure actor system to do what you want to do. This will allow "painfully sequential" code to be handled naturally, whilst the rest is done the actor way.

There are some other possibilities right now:

• Consider whether perhaps B doesn't need to be an actor. If it is just a data structure, then you can call it synchronously with normal Rust calls.
• If it is an object that needs to be accessed by various actors, then maybe you could make it a Share. Then you can access it synchronously, although the code within a shared object has some restrictions on it (e.g. it doesn't have a cx) so it can't do everything that an actor method can do. So it's good for caches or shared data structures that don't themselves need to receive events.
• If you want to keep the code to handle the returned value close to the original call in the source, then you could use inline code within the ret_some_to!, which uses the same syntax as fwd_to!. You can probably inline that ret_some_to! into the call! macro if you don't mind it formatting into various lines, which makes the sequence of operations clearer. Then it looks similar to a normal Rust call with a callback closure, e.g. something like:

call!([self.actor_b], query(
    ret_some_to!([cx], |this, cx, msg: String| { 
        println!("{}", msg); 
    }));

• The other way is to just try and embrace the actor way of thinking about things. It's a powerful approach and will comfortably allow you to handle quite difficult problems as the complexity scales up.

Without knowing your problem it's difficult to make specific suggestions. But really when designing actors it's like designing a protocol. A chatty protocol with lots of round-trips is not going to be very efficient. You try to get as much done in as few exchanges as possible. So it is with actors too.