09:27 am, 18 Feb 08
live restart
Emacs can be modified at runtime because it can just dynamically reexecute new code. But what about a statically {typed,compiled} program?
Since exec() replaces the current process image inline, as long as you serialize in and out externally-perceivable info like which file descriptors are doing what things, you can actually just exec in the new code. It's like restarting, but transparently restarting in-place. (From a mailing list: "With XMonad, you don't lose any windows, layouts, X connections or anything when you persist-and-restart; people have even upgraded several versions and restarted without any problems." [I've never used XMonad.])
Does this really work? I'm trying to think of what other sorts of state you could lose between execs. (An interesting aspect to this is that it's much easier in a language that makes you very explicit when you maintain any in-memory state.)
Since exec() replaces the current process image inline, as long as you serialize in and out externally-perceivable info like which file descriptors are doing what things, you can actually just exec in the new code. It's like restarting, but transparently restarting in-place. (From a mailing list: "With XMonad, you don't lose any windows, layouts, X connections or anything when you persist-and-restart; people have even upgraded several versions and restarted without any problems." [I've never used XMonad.])
Does this really work? I'm trying to think of what other sorts of state you could lose between execs. (An interesting aspect to this is that it's much easier in a language that makes you very explicit when you maintain any in-memory state.)
State
Right. The trick is to be able to track all state in your program. InHaskell this is trivial: either there's no state, or there's a single
root in the GC pointing to all of it (so just 'ask' for it from the
State monad).
Things that can complicate the story: unevaluated thunks need to be
forced, and functions are opaque and can't be serialised.
So yeah. "As long as" you've already serialized and restored your entire runtime and all dependencies on the kernel and native libraries, exec lets you restart.
I guess most modern software doesn't involve extensive reconfiguration, and we're accustomed to just having modern servers reboot when we want to change anything.
I mean, it's technically sweet, and, shit, I've even spent large chunks of my life implementing it (bringing up si::disksave on new ports was actually my first task on Lucid Common Lisp, not to mention making the temacs->xemacs dumper work) but really, now that machines are fast enough that all current machines are ludicrously inconceivable supercomputers when viewed from the perspective of the time that this shit was invented (back when lispms and emacs were young) it doesn't have any technical advantages that anyone except seriously low-level developers derive any advantage from. And I understand that the universities don't even produce low-level developers any more, so there are probably, like, 50k of them left in the world now. ("What, my program runs on a CPU? My regexps turn into loops of instructions? What are those?")
I'm still waiting for the gdb hack that lets you step backward to see where memory got stomped. That still doesn't exist. You know why? Nobody uses gdb any more, because perl and ruby don't use it. It's like when you hear about how the kids today don't use email. Get off of my stoop!
infernal affairs
does an x11 window manager ever have or need much internal state? :-P (lately, and until i release 2.0, i have been recompiling, killing, and restarting aewm a few hundred times a day when the mood strikes me.) i mean, irssi does something like this, but the point of keeping a TCP connection to your IRC server up is pretty obvious. hanging on to an X connection instead of tearing it down and letting the next guy open a new one seems kind of... silly. unless it wins you something.the actual problem it seems they are trying to solve here is that a tiling wm *does* have internal state, regarding/depending on on the tiling policy (i must admit i still don't see what that has to do with the physical connection, but whatev). i joke about aewm (because, come on, it has no features, it's a piece of shit, "it's easy to be portable if your software doesn't do anything" ;-), etc), but it's really the same with metacity et al -- there is no "internal" state, because everyone's agreed on how to place that state on the server in window properties, and none of it's tied to a connection.
i think we don't have an issue of implementation details on our hands here; the problem is that the EWMH only goes as far as giving us the descriptions "maximized horizontally" and "maximized vertically" to define that state, and tiling wms are doing something much richer than that. it's not *that* much different than how things were 10 years ago when we only had the ICCCM and if you wanted to make a window "fullscreen" you had nothing but internal state and couldn't cleanly communicate it with another wm (real one, or something auxilary like a pager)/a re-exec'd copy of yourself. or you just resized the damn thing and entirely broke the geometry model.
having played with some tiling wm's and appreciated the benefits, but still unwilling to invest in the trouble of setting such an environment up, i'm working on an interaction pattern for aewm 2.0 that will hopefully get closer to giving me the *benefits* of some tiling setups without having to layer on another input (i.e. keyboard... can't stand using the keyboard)/policy/configuration layer. the problem is not really featuritis or lines spent by the implementation (that's not, honestly, what this project is really about); it's about a lack of well-defined semantics for communicating the solution (that's what it is). i would like to figure something out but i may end up waiting for the current mess to come to some sort of synthesis.
i mostly ignore the wm-spec list (like i mostly ignore everything, because "i would like to" invariably means "i would like to, but bickering with other people about bikeshed color isn't worth my time") because it's all "i thought of the 728635th kind of window that should be drawn without a titlebar, help me justify saying that this hint is actually semantic"/"xinerama should do this and this and this" crap and not... trying to solve this problem. the spec is pretty hideous. product of its time i guess. the problem at hand is much more discontinuous than catching up with some doodads that apple and microsoft put in their windowing systems; it's transitioning away from physical geometry as the expression of window arrangement state. (which is really a much deeper issue than i ever hope to grapple.)
this is perhaps all tangential to your concerns, which suspect may have more to do with haskell than x11. but i think it's fair to point out that not everyone who designed "serialize all your state so you can re-exec yourself" into something set out to do that, or was even thinking of that in relation to their goals -- maybe they were just trying to make their windowing protocol network-transparent, or, you know, their hyper-text transfer protocol cache-transparent, etc.
Re: infernal affairs
wait, you've never used xmonad? huh. you did still say you had linux on your thinkpad, right? what do you use?(see also http://twitter.com/decklin/statuses/364688892)
Re: infernal affairs
oh, wait, that is the equivalent of friends-only isn't it. it just said " also, xmonad is making me feel inadequate." but i swear i was reading their page again because you mentioned it.Re: infernal affairs
I've given up on computers, more or less. I use whatever the default is on Ubuntu. The trackpoint nipple is inoffensive enough for me to not mind using the mouse.Re: infernal affairs
i'm also a big fan of the nipple (*snerk*), but i must admit i've been missing the 4th/5th scroll wheel "buttons"[1] to the point where i really think i need one with an additional touchpad just to remap the pair below it. this is probably a sign that i am attempting to do too much with the mouse.(i do kinda want to play with a macbook air though. on a purely hypothetical level i can't think of what to do with multitouch, but maybe if i used it for a while.)
[1] scroll on root window == switch desktops. i can't stand working without this.
Re: infernal affairs
This comment is awesome.condor
The condor project (http://www.cs.wisc.edu/condor/) allows mostly arbitrary programs to be stopped, serialized, and restarted on another machine with all open file descriptors etc preserved. IIRC it's done by linking to a special version of the libc.Why would you want to do it that way? That does not seem to me to be at all comparable to what Emacs (or anything else that has some form
eval) does it. It would seem to me that the right analogon is the approach from your C REPL hack, ie. loading a shared lib generated by the program itself at runtime. No?Not so: it works to the extent that you’ve broken your code into subroutines.
Either you thought ahead and wrote a small runtime so that your main code is itself loaded as a shared lib at startup, in which case you can more or less swap any symbol at runtime. Or you’re willing to be a swine, patching
JMPs into the subroutines in your initial, statically loaded program core when they’re overridden by subroutines from a shared lib.Whichever the case, you get dynamism exactly on par with what a dynamic language would offer.