Open mankinskin opened 3 years ago
So the problem seems to be that I have a tokio executor running, but riker uses the executor from futures. I'm thinking about configuring riker to use the tokio executor now.
So this is my current state.
The ActorSystem
starts the executor, which is currently hardcoded to futures::executor::ThreadPool
, which is a handle to a ThreadPool, i.e. it can be cloned.
I have tried to make this field generic using an ExecutorHandle
trait, but I realized that ActorSystem
is passed all over the crate as a handle to the ActorSystem
, so that meant adding generic parameters everywhere, which requires a lot of maintenance.
Then I tried to use cargo features to select the executor used using compiler flags. This got me pretty far, but there are some issues making the tests pass. I also had to edit riker-testkit. which seems to implement some mock actors for testing. I got it to compile, but for some reason the tests won't run through, they are just blocking and not being executed. Now I am looking into it on my forks tokio_executor branches: https://github.com/mankinskin/riker/tree/tokio_executor https://github.com/mankinskin/riker-testkit/tree/tokio_executor
I have come to believe that it would be better to migrate the whole crate to use async/await and a tokio executor, which also intersects with the discussion in #87 . I would probably remove the feature in my fork and focus on migrating the entire crate to tokio using as much async/await as possible. But I will have to get more familiar with the individual components of this crate first. Any comments or suggestions would be much appreciated.
The problem was not with riker or tokio, but rather telegram-bot.. It might be that there is an incompatibility between tokio 0.2 and 0.3
Actually, the problem was still there, even when using tokio 0.2 (in my crate). I thought the issue was that I was using telegram-bot (tokio 0.2) and with tokio 0.3, but that was not it. Even when using 0.2 everywhere, the futures executed by riker conflict with the tokio runtime.
The tokio_executor branch solves this though, by replacing the ThreadPool executor with a tokio::executor::Handle.
The code is a little bit ugly because of all the feature guards, and probably not ready to be merged in this repository. It works for my usecase right now, as I only really want to use tokio, but I would be happy to discuss how to turn this into a PR. Probably we can make the feature guards less extensive by encapsulating some parts of the code more.
@mankinskin Greetings again! I don't know it problem of Tokio or Rust, but using riker from your branch gives me about 74-76% higher RAM usage than stock lib.
@BratSinot this might well be due to tokio: https://www.reddit.com/r/rust/comments/i3fync/why_async_version_of_simple_program_use_to_50x/
I have not benchmarked this branch, but I don't think anything except tokio could allocate this much RAM. In the reddit answer they say it is not really used memory, but just virtual memory, i.e. reserved memory ready to use but not actually used.
Hi, I am having some trouble spawning a future on riker's executor. I want to spawn a stream polling future that should forward messages to an actor. Basically this is the only interesting part:
then I create the actor in my main function. annotated with
tokio::main
:Where
actor_sys()
lazily creates the ActorSystem:However when I run this with the
ctx.run
call, I get this error:Am I doing something wrong? How can I solve this? Is there a better approach?