multithreading - Rust syncronization strategy for MUD server -

multithreading - Rust syncronization strategy for MUD server -

so if had mud sever handled each tcp connection in separate process,

for stream in acceptor.incoming() { match stream { err(e) => { /* connection failed */ } ok(stream) => spawn(proc() { handle_client(stream) }) } }

what strategy sharing mutable world info server? can imagine n connections responding commands user. each command needing visit , perchance modify world.

pub struct server<'a> { world: world<'a> } pub struct world<'a> { pub chat_rooms: hashmap<&'a str, chatroom<'a>> } impl<'a> world<'a> { pub fn new() -> world<'a> { allow mut rooms = hashmap::new(); rooms.insert("general", chatroom::new("general")); rooms.insert("help", chatroom::new("help")); world{chat_rooms: rooms} } }

would arc way go?

let shared_server = arc::new(server); allow server = shared_server.clone(); spawn(proc() { // work server });

what scaling 100 or 1000 users? i'm looking nudge in right direction.

an arc allow access value multiple tasks, not allow borrow value mutably. compiler cannot verify statically 1 task borrow value mutably @ time, , mutating value concurrently on different tasks leads data races.

rust's standard library provides types allow mutating shared object safely. here 2 of them:

mutex: simple mutual exclusion lock. mutex wraps protected value, way access value locking mutex. 1 task @ time may access wrapped value. rwlock: reader-writer lock. kind of lock lets multiple tasks read value @ same time, writers must have exclusive access. same rules borrow checker , refcell have (except lock waits until borrow released, instead of failing compilation or panicking).

you'll need wrap mutex or rwlock in arc create accessible multiple tasks.

multithreading rust game-theory mud