Production. (Actix). about ractor HOT 2 CLOSED

So there's a lot here, and if you find an answer isn't clear, let me know and I'll try and clarify it.

• ractor is fully async-await in it's handlers, including startup and shutdown routines
• As you mentioned, we do have supervision but probably a bit of a different syntax than actix from my understanding

1. For web-sockets style use-case, we would create child actors which are each responsible for read and write separately. The parent actor is then your multiplexor, so you interact with that for fully-structured frames (or objects if you want to handle serialization in those layers). An example is our network session handler in ractor_cluster. This could probably be added as a wrapped helper, but unlike actix we don't have a "context" here which can interact with.
2. For a database actor, we already are async handlers so you should be good-to-go out of the box
3. Since tauri is built on tokio it "should" work fine. But I'm not that familiar with tauri so you'd need to try it.
4. So for thread-blocking work, I'd recommend using tokio::task::spawn_blocking to push onto CPU-bound tasks to not block the main runtime executor. This yields a JoinHandle which you can await on within the normal tokio Task inside the actor's handler. The linked examples from tokio show waiting on a blocking task without blocking the high-performance threads.
5. We have ActorRef<TMessage> (after the open PR merges #89)

from ractor.

Hey @slawlor Thank you for taking a look into this.
Indeed too much going on, I am going to do some testing, and wait the mentined PR mergs.

The issue can be closed. I should come back in case of questions.

Thank you once again.

from ractor.