Settings

Theme

I hotreload Rust and so can you

kampffrosch94.github.io

6 points by polanas 15 days ago · 1 comment

Reader

skullt 14 days ago

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.

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection