Dynamic loading doesn't hot reload either, more like hot load.
Debuggers might hot-patch code to insert breakpoints, but that's not the same thing as replacing running code. Sure, the debugger might execute scripts you associate with breakpoints, but that's also not exactly the same thing as replacing the running code. Mind you, debuggers do have to make sure that such hot-patching is atomic, or they have to stop all threads.
Hot reloading has a ton of considerations:
- threading -- you need to quiesce all threads at points where they are not executing the code to be reloaded _or_ you need to load the new code and hot-patch either calls to old code and/or old code function entrypoints to jump to the new code, but if the latter then you need to make sure it's ok to have a mix of threads executing old code while the new code comes online
- data structure compatibility -- if structures have changed you may not be able to hot-reload, but you need to at least be able to detect incompatible changes, and at best you need to plan how the hot-reloaded code will upgrade extant data structures on the fly
- and more
Sure, if you atomically hot-patch all the calls to old code or old code entry points, then threading issues on the side of the hot-reloading library go away, but you still have to think about how old and new code running concurrently will deal with each other.
Now, I don't know that much about this subject, and I've seen how old Lisp and Smalltalk systems could hot-patch/reload all the live long day with no problems, but I suspect all the systems where it was ever easy were a) single-threaded, b) written in high-level languages, c) still had some reloading considerations for the authors of the code being reloaded.
> Debuggers might hot-patch code to insert breakpoints, but that's not the same thing as replacing running code.
Solaris dbx did have this capability -- patch and replace code with newly compiled code from your updated source files -- circa 2000. You just typed "fix" and it worked. I've been wishing for that capability on x86 Linux ever since.
God, it was so, so convenient. Near instant turnaround time for fixes. It was especially good in combination with 'pop', which returned control to the calling function just before calling the current one. It gave you a sort of limited form of do-over, with the caveat that it didn't try to undo any effects of the called function so far. Or you could just fix and restart.
If you store all your data in mapped files, you can remap them after execve and continue where you started from. This works if the data layout hasn't changed. If you have per type memory maps, you can explicitly convert only the data that has changed. You might need redo logs for things that can't be persisted (networking for example).
Not easy, but also not impossible. All your other concerns still apply of course.
Besides therealcamino answer, Energize C++ and Visual Age for C++ v4 provided a image like development experience for C++, including code replacement and incremental compilation at method/function level.
Sadly too expensive for their day, and eventually died, only for us to start having some of those features almost 30 years later.
exec() doesn't hot reload either.
Dynamic loading doesn't hot reload either, more like hot load.
Debuggers might hot-patch code to insert breakpoints, but that's not the same thing as replacing running code. Sure, the debugger might execute scripts you associate with breakpoints, but that's also not exactly the same thing as replacing the running code. Mind you, debuggers do have to make sure that such hot-patching is atomic, or they have to stop all threads.
Hot reloading has a ton of considerations:
- threading -- you need to quiesce all threads at points where they are not executing the code to be reloaded _or_ you need to load the new code and hot-patch either calls to old code and/or old code function entrypoints to jump to the new code, but if the latter then you need to make sure it's ok to have a mix of threads executing old code while the new code comes online
- data structure compatibility -- if structures have changed you may not be able to hot-reload, but you need to at least be able to detect incompatible changes, and at best you need to plan how the hot-reloaded code will upgrade extant data structures on the fly
- and more
Sure, if you atomically hot-patch all the calls to old code or old code entry points, then threading issues on the side of the hot-reloading library go away, but you still have to think about how old and new code running concurrently will deal with each other.
Now, I don't know that much about this subject, and I've seen how old Lisp and Smalltalk systems could hot-patch/reload all the live long day with no problems, but I suspect all the systems where it was ever easy were a) single-threaded, b) written in high-level languages, c) still had some reloading considerations for the authors of the code being reloaded.