I know a couple of programs which continue to use a similar trick in the 21st century. It’s quite neat.
In the Xmonad window manager, your configuration is written in Haskell and your configuration file is actually compiled to be the effective entry point of the window manager program that runs. Since Haskell is a static language, there’s no way it could implement live-reload of configuration written in Haskell itself without restarting the process, so here’s what it does: it shells out to GHC to compile your configuration file, then it serializes all the current window state and execs the newly-compiled configuration file binary (which itself restarts the window manager with your new configuration), which then reloads all the window state from the serialized information saved by the pre-exec window manager and then continues talking to the X server over the same file descriptor as if nothing had happened. It’s comparatively easy to serialize and deserialize an entire program state in Haskell, because everything is encapsulated in a tree of immutable objects!
A similar trick seems to be used to allow the Mac OS terminal emulator program iTerm2 to upgrade without losing any live terminal state, but I haven’t looked at the source code to confirm exactly how it works. I assume it’s very similarly implemented.
Did Dikus do copyover? My academic performance was ruined by LPmuds instead, which have a VM. I always thought that was a more comprehensive approach, though the admins were perpetually worried about memory usage.
I dunno about the broader Diku family, but CircleMUD (a Diku derivative) definitely had a copyover patch available for it. LPMuds passed me by, but the driver/mudlib split with a VM does sound like a good thing.
I know a couple of programs which continue to use a similar trick in the 21st century. It’s quite neat.
In the Xmonad window manager, your configuration is written in Haskell and your configuration file is actually compiled to be the effective entry point of the window manager program that runs. Since Haskell is a static language, there’s no way it could implement live-reload of configuration written in Haskell itself without restarting the process, so here’s what it does: it shells out to GHC to compile your configuration file, then it serializes all the current window state and execs the newly-compiled configuration file binary (which itself restarts the window manager with your new configuration), which then reloads all the window state from the serialized information saved by the pre-exec window manager and then continues talking to the X server over the same file descriptor as if nothing had happened. It’s comparatively easy to serialize and deserialize an entire program state in Haskell, because everything is encapsulated in a tree of immutable objects!
A similar trick seems to be used to allow the Mac OS terminal emulator program iTerm2 to upgrade without losing any live terminal state, but I haven’t looked at the source code to confirm exactly how it works. I assume it’s very similarly implemented.
Did Dikus do copyover? My academic performance was ruined by LPmuds instead, which have a VM. I always thought that was a more comprehensive approach, though the admins were perpetually worried about memory usage.
I dunno about the broader Diku family, but CircleMUD (a Diku derivative) definitely had a copyover patch available for it. LPMuds passed me by, but the driver/mudlib split with a VM does sound like a good thing.