DAVE'S LIFE ON HOLD

Care and maintenance of long running apps

One of the great design decisions behind Erlang's process model lies not in the processing, but in it's roots in Prolog. While other languages often try to optimize through single static assignment analysis, and a great amount of research has gone into making this safe, Erlang bypasses this entirely by only allowing static assignment.

This design decision means that any process that manages state over the long term must pass along state in it's parameter list. It is a common pattern entrenched in OTP, and necessitated by the fact you can not mutate the binding of a variable.

This also means that it is easy to upgrade a process in place. OTP allows you to define a transformation for your module to upgrade an old state representation to the new one as part of the code change process. Since the VM can maintain two versions of a module at once in active processes, it can manage the migration over time without stopping the world.

This morning I started playing around with trying to do the same thing in JavaScript. While upgrades usually occur as a page reload, doing so requires dumping all state and manually attempting to resume where the system left off. While this is possible in the asynchronous process code from last night's post, it does not help the cases where you have any processes running in typical synchronous mode. Since JS does not provide us a way to identify and halt all processes, we must be careful to only use our own.

Once you do that however, it is possible not only to dump state, including th continuations for each process, but also to upgrade in place. Since ALL of the methods of one of these process functions are available via messaging we can send messages to even mutate the processes themselves:


myProcess('does','alert', function(x)  alert('new alert '+ x))

This will upgrade alert only after all the existing items in the queue have completed. We can then safely mutate the rest and use our new interface.