Actix. about crossbus HOT 4 OPEN

It is glad to see you here! and I'll summary major difference and make a simple comparison between actix and crossbus, and hope you can get a clue base on these.
both of them are capable of dealing with following data types

theoretically crossbus can do what actix does in a lower level way along with more compatibility. but if you wanna use corssbus as an alternative of actix, there are some major differences you should take an eye on:

the way that crossbus take to tackle async/await is, to some degree, different from that actix takes.
crossbus just implement Future routines and defines asynchronous event handlers, not the way actix-rt (dependency of actix) takes to directly interact with runtime.

take a more specific example, actix has a set of trait and types to asynchronously handle Message request and directly await the returned response future base on what a lot of crates create services / features / functions, like actix-web, actix-net, but crossbus don't do that way, it use the similar way as javascript callback does (in case you familiar with), you just send the message request and set the handler for the ready response, crossbus will do the rest for you.

So if you wanna an easy version of actix, the answer is obviously NO,

• you have to implement runtime (though in practice, it's easy)
• crossbus does not have rich ecosystem as actix

from crossbus.

Hey @hominee Thank you for taking the time to look into this, and pull up the good informations provided.
I have a couple of questions;

Take for instance the following snippets from actix;

impl Handler<DbOperations> for McActor {
    type Result = String;
    //type Result = ResponseFuture<String>;
    fn handle(&mut self, msg: DbOperations, ctx: &mut Self::Context) -> Self::Result {
        return match msg {
             DbOperations::Get { key } => {
               block_on(async {
                    sqlx::query_as::<_, DbOperationValues>(select_query)
                        .bind(key)
                        .fetch_one(self.db.as_ref().unwrap())
                        .await
                        .unwrap()
                }).value
                 
            }
            DbOperations::Set { key, value } => {   
                block_on(async {
                    sqlx::query_as::<_, DbOperationValues>(insert_query)
                        .bind(key)
                        .bind(value)
                        .fetch_one(self.db.as_ref().unwrap())
                        .await
                        .unwrap()
                }).value
            }
        };
    }
}

Since Can not use actix way handling future and returning its value with atomicResponse, i used block_on which as result, blocks the thread, causing the system to crash specially in the case of using websockets and while blocked a Pong response is not sent, not to mention other issues.
Now the question, how does crossbus handle futures?
Please do not tkae me wrong here and later on, I like to get clarifications before i digg deep inside the crate.
2. Question; In the table mentioned the ablility to handle streams is available, so am assuming it wont be an issue handling websockets streas read/write within the actor?
3. Question; In terms of platforum, it is neccersy to compile for linux/mac/windows, I notice on the crate page linux/mac only, can you clarify that for me please?
4. Question; Does crossbus have the concept of actor to actor messaging throught threads? Say actorA on thread 1, has a referrence of actorB on thread4, and they are able to pass messages and responses.

Being said, I am thankful to your time here, I am on the phase of finding the right candidate to move on with, not necsserly will opt in but it is always good to know my options.

Thank you.

from crossbus.

few separate points are stressed regarding to your problem:

• if you wanna know explicitly how crossbus handle futures, there are some stuff out there you can refer to: how to explicitly handle asynchronous task with crossbus, the integration test contains some detailed example to use blocker delayer, streaming.
• crossbus is able to handle any types implemented Stream trait just as actix does, and Websocket is essentially a stream of message you can read / write, but crossbus doesn't define / manipulate Websocket directly. this also happens to actix if I recall correctly, actor websocket is a derivative type on top of actix. So crossbus is not your best option if websocket stuff is touched during development
• it terms of platform, I did test it in windows and tell the docs.rs to make compilation for windows as you you check the targets.package.metadata.docs.rs field in the Cargo.toml, and don't know why it doesn't display, maybe I will fix that in the next version and thanks for this issue.
• Since crossbus is runtime-less, some thread-based features like multi-thread are not supported, and it's up to the runtime implementor. However it is nothing to do with the messaging interaction (sending, receiving and handling) between actors. that is a difference that I mentioned above that actors are controlled by thread-based arbiter in actix, while those are maintained by a single global static reactor in crossbus.

Last but not the least, I don't recommend you to use crossbus given the situation you provide, instead, you should dig deeper over actix.
As your problem is as simple as to replace block_on with Context::spawn or Addr::send, no more bother to do something else.

from crossbus.

Agreed. @hominee Thank you for your time.
I am going to try and see what i can do.
Issue can be closed. Thank you.

from crossbus.