Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subsecond: A runtime hotpatching engine for Rust hot-reloading

docs.rs

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#31

Post by 1oooqooq »

jkelleyrtp wrote: post #10
1oooqooq wrote: post #9

Earlier quoted context omitted.

can't access the xitter posts... is the axum part using the whole of dioxus or bare axum + code reloading?

There's a custom `axum::serve` equivalent we built that wraps the router construction in a hot-patchable function. When the patches are loaded, we reset the TCP connections. It's a little specific to how dioxus uses axum today, but we plan to release an axum-only integration in the future.

awesome. thanks. i will definitely follow the project and hopefully participate. lack of hot reload for the FE folks is the biggest blocker we get from other options.

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#32

Post by ameliaquining »

eigenspace wrote: post #28

I would recommend looking into how julia handles code reloading with our builtin infrastructure and the Revise.jl package. Basically, every method to a function and as of v1.12 (currently in beta), every binding and struct definition has a "world-age" associated with it. Basically, julia is dynamically typed, but inside a function it acts like a statically type language within a fixed world-age. So that means that ba…

This sounds cool from a language-design perspective, but impossible to use a design like this in Rust. Unless I've misunderstood how it works?

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#33

Post by ameliaquining »

written-beyond wrote: post #15

I really want rust dylibs to be a reality. A plugin system where a library can implement a specific versioned number of a trait and we can dynamically load in that implementation to get changed behaviour. Right now implementing anything like that requires a lot of unsafe which I'm not comfortable with.

Do stabby and abi_stable not work for your use case?

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#34

Post by mdaniel »

cyberax wrote: post #19

Can we have the same for Go, pretty please?

> The gist of it is that we intercept the Rust linking phase and then drive `rustc` manually. There's some diffing logic that compares assembly between compiles and then a linking phase where we patch symbols against the running process

makes it sound like it's actually not super rust specific, just a ton of squinting at assembly dumps. I do wonder if there are some "reproducible builds" traps hiding in this, but maybe it just needs to be selective about what it patches, and that turns out to be the really hard problem

I didn't follow the tick() problem cited elsewhere, but my mental model is that, sure, one should not patch currently executing code without expecting "well that didn't do what I wanted" type shenanigans

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#35

Post by vlovich123 »

jkelleyrtp wrote: post #6
weinzierl wrote: post #4

Very nice. For a long time I wondered who would use hotpatching but working with large Java applications made me appreciate the possibility even if it is not 100% reliable (as it is in Java). From the docs Subsecond looks almost perfect. The only downside I found is that (if I understood correctly) you have to modify the function call in the source code of every function you want to hotpatch. It is a bit mitigated in…

Creator here - you only need one `subsecond::call` to hook into the runtime and it doesn't even need to be in your code - it can be inside a dependency. Currently Dioxus and Bevy have subsecond integration so they get automatic hot-patching without any end-user setup. We hope to release some general purpose adapters for axum, ratatui, egui, etc.

Could there be general purpose adapters for something like tokio more broadly so that if I have an app that’s not based on a framework I can leverage this?

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#37

Post by toast0 »

weinzierl wrote: post #4

Very nice. For a long time I wondered who would use hotpatching but working with large Java applications made me appreciate the possibility even if it is not 100% reliable (as it is in Java). From the docs Subsecond looks almost perfect. The only downside I found is that (if I understood correctly) you have to modify the function call in the source code of every function you want to hotpatch. It is a bit mitigated in…

> For a long time I wondered who would use hotpatching

As someone who used a lot of hotpatching and now can't...

This isn't aimed at production, but ... Hotpatching is essential to update code without losing program state. A lot of people work in http request/response stuff and program state lasts the duration of the request/response; you don't usually need hotpatching for that unless your responses are very long --- there's lots of ways to swap in new code where requests after some time hit the new code and requests that started in old code finish and that's usually what you want.

If you've got something with long requests and you might want to change things during the request, hot patching is needed. If you've got something with long running connections or some other elaborate session, hot patching eliminates a lot of disconnect/reconnect session movement and lets you get everything running on the new version with a lot less hassle; as long as you accept the hassles of hot patching.

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#38

Post by anp »

jkelleyrtp wrote: post #18
jesse__ wrote: post #14

Earlier quoted context omitted.

Strong agree here. The 'purity' BS of not modifying the running programs address space appears to come at the cost of significant programmer pain-in-the-ass. Having to hand-hold the library to maintain the indirection table is a hard no for me. Metaprogramming that maintenance burden seems like it should be relatively straight-forward, if you've written a linker already.

The challenge is that if the program is busy in a spin loop, there's no way to preempt it and modify it. Things like malloc, spin loops, network requests, syscalls etc. I looked into liveplusplus a lot and their unreal integration also requires a broker to get the most out of it. If you're building a game engine and want to support struct layout and alignment changes, you'll need to do some re-instancing. Hiding a `s…

FWIW I think the project is quite cool even if you “only” manage to roll out the subsecond integration into popular ecosystem runtimes.

Have you considered aiming at lower level dependencies that are even more ubiquitous? Like libc functions?

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#39

Post by jkelleyrtp »

anp wrote: post #38
jkelleyrtp wrote: post #18

Earlier quoted context omitted.

The challenge is that if the program is busy in a spin loop, there's no way to preempt it and modify it. Things like malloc, spin loops, network requests, syscalls etc. I looked into liveplusplus a lot and their unreal integration also requires a broker to get the most out of it. If you're building a game engine and want to support struct layout and alignment changes, you'll need to do some re-instancing. Hiding a `s…

FWIW I think the project is quite cool even if you “only” manage to roll out the subsecond integration into popular ecosystem runtimes. Have you considered aiming at lower level dependencies that are even more ubiquitous? Like libc functions?

Yeah not sure why someone's first reaction to seeing 150ms Rust hot-patches is to call it BS and a "pain-in-the-ass." Tough crowd.

We could aim lower, or make it entirely automatic. The first prototype was entirely automatic, but I realized that you definitely need to signal to the program to hot-reload.

For code like:

```rust

while true {

    let msg = io.poll();
}

```

you're now stuck because the program is hung on a syscall. Doesn't matter if you hot-patch the loop, the program is stuck. My first prototype used the exception tables to unwind the program, but that didn't work on WASM and led to weird issues with cancellation and effects.

Similar issues with one-time initialization code at the beginning of the program. You could just hot-patch from `main` - basically restarting the program - but the whole point of hot-patching is that you can keep as much state around as possible while also changing its behavior.

For most apps, you just need one `subsecond::call()` and it works. The bevy folks wrote a `#[hot]` macro which we might integrate, but I'm also keen for frameworks to just adopt it and/or distribute a simple universal adapter.

Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading

#40

Post by juancampa »

jkelleyrtp wrote: post #6
weinzierl wrote: post #4

Very nice. For a long time I wondered who would use hotpatching but working with large Java applications made me appreciate the possibility even if it is not 100% reliable (as it is in Java). From the docs Subsecond looks almost perfect. The only downside I found is that (if I understood correctly) you have to modify the function call in the source code of every function you want to hotpatch. It is a bit mitigated in…

Creator here - you only need one `subsecond::call` to hook into the runtime and it doesn't even need to be in your code - it can be inside a dependency. Currently Dioxus and Bevy have subsecond integration so they get automatic hot-patching without any end-user setup. We hope to release some general purpose adapters for axum, ratatui, egui, etc.

Amazing! Looking forward to the egui adapter
Post reply on HN