stakker async await

[janjaapbos]

I have been looking at async await (https://github.com/uazu/stakker_async_await) but do not understand how to use it in a method of an actor that can be executed with the call! macro.

I order to use a ret_to_future inside the method, the method needs to be async. However, calling that async method with call! macro, gives an error.

Could you perhaps give an example how to use ret_to_future in an actor's method? Or perhaps this is not supported, in that case I am curious to know what the use case is of stakker async await.

[janjaapbos]

So I looked a bit further, and was able to to use a ret_to_future with spawn_future in an actor method. I am still researching what the actual benefits are, because within and between actors, it seems simpler to use the regular Ret instance.

[uazu]

This crate is a proof-of-concept for integration between Stakker and Futures, Streams, the async/await ecosystem, etc. As you probably know, a lot of async/await code depends on a particular runtime. There is little I can do about that. However I can try to support async/await code which is designed to work with any runtime. So the benefit of combining spawn_future and ret_to_future (or similar) would mean that some async/await library that worked directly with Futures or Streams could be called from Stakker, and would operate asynchronously alongside Stakker-based code in the same thread. Right now cross-thread waking is not yet implemented, but is in principle not too hard to add.

If you look under tests there are some more examples there. I wrote all this code to contribute to the async/await investigation that Niko did some time ago. I think the general aim is to try and see if we can meet in the middle somehow, i.e. create an ecosystem of code which doesn't depend on a particular runtime. However until there is a fair amount of code out there that is runtime-independent, perhaps there isn't too much use for this crate.

If you have a particular use-case and this crate is almost what you need, I'd be happy to look at extending it to try and cover what you need.

Another direction I might possibly go with this is to use it as a way to support actor coroutines written with async/await syntax. However there is a problem of getting borrows through the context, meaning dynamic checks are required, and I was kind of leaning towards another slightly purer way of implementing those, even though it would be more work.

[janjaapbos]

Thank you very much for the explanation.

Just to let you know, I really like Stakker as a framework. It really meets its stated goals, such as simplification of borrowing and rust lifetimes. For me as a novice rust user, it helps as a foundation to create applications in a concise and clear manner. Altogether using a minimal stack and almost no external dependencies.

During the past couple of weeks I have created an integration library for Stakker with NNG (https://github.com/neachdainn/nng-rs). I will make it public when I have it ready for review & feedback. I am able to create actors locally and remotely, and interact between them over all the NNG network transports, including ZeroTier.

[uazu]

Thanks! Stakker comes out of 15+ years of experience with writing similar software in various languages. It closes off a lot of troublesome failure scenarios that I've faced in the past. Thanks to Rust, trying to code those scenarios would give a compilation error. These are problems that the wider async/await ecosystem is still facing, such as nested spawns and so on. So whilst it seems minimalist, a lot of hard-won experience has gone into its design. I'm not sure how to promote it further when so much energy and enthusiasm is devoted to other runtimes, but anyway in small ways it is gaining traction. For example the company I work for has several products that are or will be using it, and it has met its design objectives in that scenario (e.g. integration with C++ event loops, or running standalone, etc).

Let me know when you have your NNG integration ready to look at. That is certainly something of interest. If you need feedback at any point, I'd be happy to have a look. I will find somewhere in the docs where I can mention it and link to it. Remote actors were something I had planned, but weren't an urgent requirement. I have an actor failure reason StopCause::Lost ready for proxy actors that fail because they lost their connection to the remote. I'd be interested to see how you've made this work, because I hadn't fully thought this through yet.

[d4h0]

@uazu: Are you aware of Glommio?

Glommio is a thread-per-core async runtime for Rust, and I'm wondering if there would be any benefit to integrate with the async ecosystem via Glommio, instead of something like stakker_async_await.

Glommio currently doesn't have much support in the Rust community, so this wouldn't solve any problem in regard to crates that are written for specific runtimes, but I thought maybe there could be some benefit because both systems are thread-per-core.

[uazu]

I hadn't read seriously about Glommio, but I have now. Their model is essentially an extreme version of what I see as how a single-threaded runtime like Stakker should scale, i.e. using sharding or high-level load-balancing, and try to minimize context switches or inter-thread communication (except where unavoidable). It would definitely be a close match in approach. I would have to get into the details to see how well I could interface with it all.

Essentially what Stakker could offer to Glommio is a low-level high-performance actor system, and it would let people who like actor systems code easily on top of Glommio. I don't think it really helps much in terms of integrating with the async/await ecosystem in general, as you say. Something like Glommio is a good example of why we need more runtime-independent async/await crates, though. Integrating with Glommio is an interesting idea.

[d4h0]

One major benefit for Stakker from a binding with Glommio would be, that this would make Hyper available, which would make it possible to implement web applications (and frameworks) on top of Stakker.

On the other hand, maybe the same approach, as linked above, just could be used with stakker_async_await directly...

[uazu]

I've added #28 to keep a note of the idea. As I mentioned there, I think it would be better to put time into cross-platform async/await support, but maybe I can borrow ideas and workarounds from Glommio.

[d4h0]

Thank you! Yes, cross-platform async/await support probably offers a better Return-on-Investment (especially, if Glommio's approach for integrating Hyper works with it).