xactor
xactor copied to clipboard
sunli829
Xactor is a rust actors framework based on async-std
Since Caller is the equivalent of a channel's Sender, I would expect to be able to freely clone it. I am aware that I can get around this if I...
Hi there, as described in #27 it would be really nice if `Supervisor`s could be stopped. I would like to propose to add the `.stop_supervisor()` method to `Addr` and `Context`...
this adds `Caller::can_upgrade()` and `Sender::can_upgrade()` so you can check if they're dead without having to construct a `Message`. This probably fixes #49. Thank you
Hi there, I just noticed that `Sender` and `Caller` just return an error when sending the message. For convenience it would be nicer if you could test if they can...
Why use anyhow::Error, I don't get why it is needed, it leaks the interface so I have to add anyhow to my dependencies if I want to handle errors from...
Hi there! Hope you're having a nice day. I just started looking into this code base again and found that EDIT: sorry, I seem to be bad at finishing my...
While using xactor to build an IRC server, I realized that I wanted a different implementation for actors' message queues, so that they would respond to backpressure from other parts...
Currently if I spawn multiple actors: ``` let _daddr = DownloadActor::start_default().await.unwrap(); let _daddr2 = DownloadActor::start_default().await.unwrap(); ``` and then publish a job: ``` Broker::from_registry().await.unwrap().publish(msg) ``` the effect I get is that...
As far as I understand, on most actor implementations, different actors can process their own messages in parallel with respect to other actors, which makes things go faster. But I...
As far as I understand the current implementation of [`start_actor()`](https://github.com/sunli829/xactor/blob/272b1b49fa9f387afe70c4056be2ab8b4284118f/src/actor.rs#L140) will process messages sequentially. The next message will only be processed, once the previous one is completely processed, even if...
