I've thought such DSU system for a while, and it came to me that using a simple fork/exec technique require you to save (or dump) you data somewhere, before the exec() call. If you do it with a file and your data is huge, your update is no longer "seamless". :-/
Some research (a while ago) showed me that exec() on Linux call may be parameterized in order to prevent it to cover data segment (while I am not 100% sure), but then I think it exist only for Linux and is not portable.
Seems like a ton of work to get this implemented into an application, and it also seems error prone (the amount of work they described to get memcached moved over, for example, sounds like it had lots of room for mistakes). And if there's anything I don't want to have room for subtle mistakes, it's live-updating a server or other critical piece of infrastructure.
The approach seems interesting, though, and it's cool to see them demonstrate that the performance impact is negligible (updates seem to apply very quickly based on their tests, too). Maybe there's a use case for this where the risk of mistakes causing failed updates/corruption is low?
It'd be incredibly interesting for MUD development, if anyone still did that. No need to kick everybody out for bug fixes, just post a new build. Actually, I could see it for any game with a lot of built-in state that's hard to set up between test runs: Dwarf Fortress, physics engine tuning, that sort of thing. Make it work on the PS3 and XBox 360 (and with C++!), and you've got the start of a legitimate middleware company.
Saved in my "in case I ever go back to hacking on Nethack" folder.
Console vendors will probably never allow this kind of live-patching. Updates have to go through certification.
For most games I know of that do live updates, they just do it by booting up a new version of the server and 'switching' people over when they cross boundaries (most MMOs still have loading screens and server transitions, so it's not that hard). Client updates are certainly more difficult, but I'm not sure you'd ever do it - there's no way you're going to get NVIDIA or AMD to apply this technique to their video drivers, etc.
I was thinking of it as a tool for shortening dev cycle time, more than for patching: a more general, cross-platform version of Edit and Continue. My mistake; I shouldn't have started with the MUD example, I was just writing out my thoughts in real time.
9 comments
[ 2.2 ms ] story [ 18.9 ms ] threadSome research (a while ago) showed me that exec() on Linux call may be parameterized in order to prevent it to cover data segment (while I am not 100% sure), but then I think it exist only for Linux and is not portable.
The approach seems interesting, though, and it's cool to see them demonstrate that the performance impact is negligible (updates seem to apply very quickly based on their tests, too). Maybe there's a use case for this where the risk of mistakes causing failed updates/corruption is low?
Saved in my "in case I ever go back to hacking on Nethack" folder.
For most games I know of that do live updates, they just do it by booting up a new version of the server and 'switching' people over when they cross boundaries (most MMOs still have loading screens and server transitions, so it's not that hard). Client updates are certainly more difficult, but I'm not sure you'd ever do it - there's no way you're going to get NVIDIA or AMD to apply this technique to their video drivers, etc.
First, they tested their update methodology by applying it to a long history of released versions for each piece of software.
Second, although any code involving concurrency is tricky, I thought the line counts were actually quite low:
where C LoC is the original program length, C delta is the changes to the program, and xfgen LoC is extra specification stuff they had to write.Third, how is a broken online update any worse than a broken offline update? Is there a greater argument for data loss?