#actor-model #virtualization

bin+lib sids

Sids is a sample actor-model scheme providing abstraction over actor types and messages that can be sent across threads

3 unstable releases

new 0.3.1 Nov 19, 2024
0.3.0 Nov 18, 2024
0.2.0 Nov 17, 2024

#228 in Concurrency

Download history 247/week @ 2024-11-14

247 downloads per month

Apache-2.0

28KB
439 lines

SIDS - An Actor Model Approach to Data Collection in RUST

This is an experimental actor-model system library built in rust. The repository has a few Mermaid diagrams and exxamples available for you to examine if you are interested in implementing the approach yourself.

Getting Started

Run the example logging demonstration.

git clone https://github.com/professor-greebie/sids
cd sids
cargo run --example loggers

What this does

This project demonstrates a simple approach to building actors in Rust, allowing for some abstraction between Tokio-type and blocking actors.

This is still a project in development, but it does illustrate how you might develop an actor system from scratch in Rust.

Basic Concepts:

An actor - an actor implements an Actor Trait to include a receive function that accepts a message type of Message<MType>.

The Message struct covers the most common Actor behaviors (stop, responses etc.), but you can add more as part of the payload, which is of type MType.

MType can be any base type (String, u32 etc.) or an enum provided that it has Send features and can have static lifetime. Enums are powerful in Rust, so they are highly recommended. See the Rust documentation on enum types for more information

Once you choose an MType, then the ActorSystem will use the same message type throughout the system. Currently, only one MType is allowed, however, with Rust's enums, there is a lot of capacity for variance on the types of messages that can be sent.

let mut actor_system = sids::actors::start_actor_system::<MType>();

Starting an actor system initializes the system and runs a 'boss' actor called the Guardian with an id of 0. You can ping the boss using sids::actors::ping_actor_system(&actor_system);

You can add an actor to the system, by creating a structure that implements the Actor trait. All actors in the system must receive a Message.


use sids::actors::actor::Actor;
use sids::actors::messages::Message;
use log::info;

enum MyMessage {
    HELLO, GOODBYE, GHOST
}

// you can include some attributes like a name if you wish
struct MyActor;
impl Actor<MyMessage> for MyActor  {
    // in future this may not need to be async
    async fn receive(&mut self, message: Message<MyMessage>) {
        if let Message { 
                // optional payload contains MyMessage
                payload, 
                // boolean that tells Actor whether it should stop after message.
                stop, 
                // optional tokio oneshot channel to send a response back to sender.
                // This response with a ResponseMessage that includes SUCCESS and FAILURE messages.
                responder, 
                // optional blocking channel to send a response back to sender if the Actor is intended to be blocking.
                blocking 
                } = message {
                    if let Some(msg) = payload {
                        info!("Message received {:?}", payload);
                    }
                    if let Some(respond) = responder {
                        respond.send(ResponseMessage::SUCCESS);
                    }
                }
    }
},

#[tokio::main]
async fn main() -> Result(()) {
    let my_actor = MyActor;


    let mut actor_system = sids::actors::start_actor_system::<MyMessage>().await;
// gets a oneshot channel to receive a response from the system.
    let (tx, rx) = sids::actors::get_response_channel(&actor_system);
    let message = Message {
        payload: Some(MyMessage::HELLO),
        stop: false,
        responder: tx,
        blocking: None 
    }
    spawn_actor(&mut actor_system, my_actor, Some("My Actor".to_string())).await;
    // guardian is 0, so our actor id will be #1.
    send_message_by_id(&mut actor_system, 1, message).await;
    if let Ok(response) = rx.await {
        info!("Response received from actor {:?}", response);
    }

} 





Officers will be kept in a vector in the GuardianActor, so its id will be as per the index. In future there will be a better approach to capturing actors by name or type. To send a message to this actor, you simple do:


send_message_to_officer_enum(
    &actor_system, // the actor system
    0, // the officer id, currently a simple Vec index for now
    Message::RequestStatus, // the message you wish to send
    false // whether the actor is a thread-blocking type (see below)
    );

Actors may also be blocking in case you need that for collecting data from an http response or something else that requires thread blocking in order to operate. Blocking actors are kept in their own Vector, so indices will need to account for that (for now).

The Future

From a prototype perspective, this is final version of this project, except for performance and safety tweaks.

We will also include some more advanced examples, including using the Actor System to do Actor-Critic Machine Learning work.

Citations

The following resources helped me a lot during the building of this demonstration.

  • Mara Bos (2023) Rust Atomics and Locks: Low-level concurrency in Practice. O'Reilly Press.
  • Alice Ryhl (2021) Actors with Tokio [Blog Post].

Dependencies

~3–9.5MB
~85K SLoC