I hotreload Rust and so can you(kampffrosch94.github.io)
kampffrosch94.github.io
I hotreload Rust and so can you
https://kampffrosch94.github.io/posts/hotreloading_rust/
1 comments
If you're paying the cost of serializing/deserializing the whole game state around every reload of the worker, why bother with the unsafe type-erased PersistWrapper (which still requires you to restart the host any time the game state struct changes)? Just keep the game state entirely on the worker side, and have the host instead pass, say, a &mut dyn Write to the before/after_reload functions. The old worker can write whatever it feels like there, JSON or whatever else, on the assumption that the new worker will decode it somehow. The new worker then stashes the deserialized game state in a static Mutex<GameState> during the after_reload hook and the actual hot_update function goes back to taking just the host trait object. The big advantage here is you can change the game state struct during a hot reload as long as the deserialization can handle it. With JSON, for example, adding new fields to the game state struct would be perfectly fine: old fields still get deserialized and new fields get default initialized.