5 ms·

This is interesting. Google Chrome can patch binaries and the Linux kernel can be patched while running. I would like this capability for general purpose soft

• TeMPOraL 3y ago
  > I would like this capability for general purpose software, hot code reloading. Can do seamless non-breaking changes to a live server without a full restart. This is very old-school style, that fell out of favor for... whatever reason this industry likes to make two steps forward, and then 1.9 steps backwards. It survives in the legacy of Smalltalk and Lisp. To a lesser degree, it's featured in Erlang, and I hear C# these days. > Would have interesting interactions with socket connections using the old code and connections using the new code and all the complicated states you can get into, if your data structures are different. If you make a mental shift - treat the OS as runtime, and processes as functions (and shell as a REPL, and environment variables as dynamic binding...) - then the ideas from Smalltalk and Lisp image-based programming will apply directly. At Kubernetes level, I suppose Erlang's take on connecting BEAM runtimes applies as well. > How do you move data if you added a field to your data structure? Presumably if you added a field, there isn't enough memory allocates in the existing data structures... Your malloc is for the wrong size. If this is C (or Rust, I suppose?), then you can't. You have to architect for that from the start. With garbage collected runtimes... I'm not sure how hard is it with static typing, but with dynamically typed languages it's not bad. If you want to see a system that embraces runtime modification of classes, check Lisp (e.g. Common Lisp) or Smalltalk. For example, in case of Common Lisp, if you want to make a substantial runtime modification to some class definition, you have to supply a "old" -> "new" migration function, which will be applied to all existing instances of the old class definition. Note: this is not a hack, it's a legitimate feature of the language/runtime, and - like everything else - can be operated fully automatically.
  • kazinator 3y ago
    The thing is, you have to test and debug that. Even if I'm working with Common Lisp, I don't necessarily want to go there. Say there are five versions of your image out there, versioned 1 to 5. Users might be doing any of these upgrades: to from 1 2 3 4 5 1 X X X X 2 X X X 3 X X 4 X Assuming nobody does downgrades, we have ten combinations to test. Anything you do to reduce the testing comes at the cost of inconvenience to the user. You can support only upgrades by one; so someone going from 1 to 5 has to upgrade to 2, 3 and 4. You can cut off upgrade support for old versions; if a 1 user wants 6, they will have to suffer a stop and restart. That all just seems half-assed; you're not doing a perfect job of "no restarts ever", so why bother. No restart upgrades handle the volatile objects in RAM. Regardless of that, applications have to handle the persistent data formats: like objects written to storage by version 1, 2, 3 or 4, which now have to be processed by 5. People who understand and deal with with upgrades to persistent data, and protocols, and whatnot, are not going to react kindly if you tell them, "hey, you can add to the complexity and amount of work by hot-loading code, and dealing with upgrading across multiple versions of in-RAM volatile objects, too!". Threads throw a monkey wrench into the blender also. If the application is multi-threaded, you will have some existing threads executing old versions of functions, after they have been redefined, with threads also calling new versions of functions. An old version of a method might not play nice with the new version of an object and vice versa. You may need a partial stop and restart: the application image as such may be running, but you put some threads into a quiescent state during the upgrade. Someone has to test all that.
  • ilyt 3y ago
    > This is very old-school style, that fell out of favor for... whatever reason this industry likes to make two steps forward, and then 1.9 steps backwards. It survives in the legacy of Smalltalk and Lisp. To a lesser degree, it's featured in Erlang, and I hear C# these days. The reason is very, very simple: It's hard to do right at any level of complexity. Imagine simple cache server: what about the cache? If binary format changed, you either have to have some migration code or you need to throw it away. Once you threw the cache away you might as well just restart the server in the first place, if you want availability you need 2+ servers anyway so it buys you few seconds of boot time at most. If all you need to replace is a bunch of function calls sure, that's doable but what if new function takes some extra arguments (or just struct that it gets passed changes) ? If you have well-defined lines (like plugin APIs to use, or ability to load the "logic" part as separate thing) it can work but otherwise it is a LOT of work and bug potential to gain not that much. Better to focus on making seamless update (in case of apps used directly by users), or in "server" apps realize you need redundancy, code reload or not, so just focus on good deployment process.