←back to thread

Subsecond: A runtime hotpatching engine for Rust hot-reloading

(docs.rs)
217 points varbhat | 2 comments | 24 Jun 25 18:58 UTC | HN request time: 0.567s | source
Show context
modeless ◴[24 Jun 25 23:43 UTC] No.44372252[source]▶
Interesting, but the documentation makes it sound like you have to preemptively wrap all the code you think you might want to change in a special wrapper "call" function. If true that makes this a lot less appealing than existing solutions for other languages that can modify any function without special annotations.
replies(3): >>44372473 #>>44373126 #>>44373784 #
jkelleyrtp ◴[25 Jun 25 00:20 UTC] No.44372473[source]▶
You basically need to wrap your program's `tick()` function. Otherwise you might be in the middle of malloc, hot-patch, and your struct's layout and alignment changes, and your program crashes due to undefined behavior.

The goal is that frameworks just bake `subsecond::current` into their `tick()` function and end-users get hot-patching for free.

replies(2): >>44372778 #>>44373135 #
1. jesse__ ◴[25 Jun 25 02:26 UTC] No.44373135[source]▶
How would you preempt the running program during malloc? Isn't there a well-defined reload point? Major red flags going up if your program can just change at any random point..

Also, didn't the article say explicitly that struct layout changes aren't supported??

replies(1): >>44373237 #
2. anderskaseorg ◴[25 Jun 25 02:48 UTC] No.44373237[source]▶
There is a well-defined reload point—it’s the `subsecond::call` wrapper around `tick()`. But the hypothetical design that you seem to have in mind where this doesn’t exist would not have a well-defined reload point, so it would need to be able to preempt your program anywhere.

Layout changes are supported for structs that don’t persist across the well-defined reload point.