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

[Daniel Pittman]

jm <jeffm at ghostgun.com> writes:

>> 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.

Usually, even those changes don't disrupt application operation — and, these
days, the cost of multiple bits of hardware to handle your application is so
low that it is trivially to deploy them. :)

[...]

>> 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.

Well, actually, the applications we run at work have this, and are working
toward significantly more uptime.  They are all Perl and require a standard
shutdown / restart process to upgrade; we just engineer around that by
ensuring that the upgrade process is flexible enough.

So, the extra abstraction (or, rather, software layer) is required to help
deliver this, but Erlang isn't.  It just makes some of it easier by providing
a standard baseline under which to run the software.

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

*nod*  If nothing else, it matches the way I think about a lot of software.
Message passing abstractions really are the way of the future, IMO, because
the decades have consistently shown that this is the most flexible strategy
for handling most any information manipulation.

It isn't free, sure, but the benefits usually make up for that.

Regards,
        Daniel