[clug] Random Thought: support for Hot-code swap in the kernel

[jm]

>
> My knowledge may be out of date; I don't do any professional work with Erlang,
> so my knowledge is limited to playing around at home.  Anyway, the basic idea,
> that you can run multiple cooperating instances and use those to migrate
> should stand.
>
> (Specifically, I am confident of that, because Erlang targets systems with
>  zero percent downtime, and achieves it, in production.  When run by experts. ;)
>   

What do you made me think along these lines. The only time you'd 
absolutely have to stop an erlang application is if you up grade the vm 
it's running on or the OS the VM is running on. Ignoring the migrate 
between machines solution. It's just a that a large set of applications 
have to be stopped to upgraded and then restarted especially when you 
start talking web or network based services.

> The code, my boy.  The code.
>
> Look, you know how the ELF interpreter works, right?  It reads the ELF segment
> descriptors from the files, maps them into memory, adjusts permissions on the
> pages, then performs dynamic linking to join all the bits together, right?
>
> When you want to change the code version you just reverse the process: ensure
> that everything stops execution somewhere safe, serialize or mark your data as
> needed, unmap the code and data as appropriate (exempting the tiny core of the
> "code upgrade manager"), find the new code, then act like the ELF interpreter,
> except preserving what is presently in memory.
>
> For sanity I would probably pick a dynamic entry point for resume that acted
> like the default dynamic libc startup point, in that it called into (some
> equivalent of) main, which would know that it needed to reconstruct all the
> state, then call into my main loop.
>
> main would, obviously, construct rather than reconstruct state, then call into
> the same code path.
>
>   

ok.
>> How would you pick where to start? Have set of marshall points though out
>> your program at which the program may update and resume at?
>>     
>
> Pretty much, yeah.
>
>   
>> and this information is conveyed to new version which resumes at that
>> point. This would imply an event loop style program would it not?
>>     
>
> It isn't strictly necessary to do it that way; it would be reasonably sane to
> have an FSM based application do this check on all edge transitions, or you
> could just inject "checkpoint" calls somehow.
>
> An event loop style program would be *MUCH* easier, because there is a well
> defined "the application is at rest" point, but there is no specific technical
> reason you couldn't do this in whatever style of application you wanted.
>
>   

yeah, I was reducing to the logical conclusion.

>>> Anyway, nothing you are asking for is even particularly difficult.  The reason
>>> that it is more common in VM hosted environments is that they almost always
>>> inherently build in the dynamic linker, and probably even the compiler, not
>>> because of any inherent difference in their abilities in this area.
>>>       
>> Would it be possible to produce a C-library to do this "today" then?
>>     
>
> Sure.  Not easy, and doing something that supported more than one programming
> style would be much, much, much harder, but there is nothing to stop you.
>
> Heck, there is nothing to stop it running on much older kernels just as
> effectively, because none of these facilities are new or different; most of
> them go all the way back to prehistoric versions of Unix.
>
> Regards,
>         Daniel
>
> Personally, I like the erlang style approach of allowing multiple concurrent
> versions during the transition, run in different processes.  Because it is so
> much easier to understand it costs a lot less to build.
>
> Failing that, picking a language environment that has already solved the
> problem will save both time and money, because it is possible, but not easy.
>   
It's a pity such features are so language dependent and rely on 
yet-another-layer-of -abstraction.

Although I haven't written anything serious in Erlang it's my language 
of choice for playing around in at the moment.

Jeff.