In Part 1 , we talked about the problems in trying to hot reload a CH module. Before talking about our progress, I would like to mention a few problems in plugins package. The plugins package is currently not maintained well and does not work correctly with all recent versions of ghc. Particularly, module loading does not work when a third party module is given as input on 64-bit architecture.…
We want to achieve message passing reliability as in case of Erlang during a code upgrade. In an earlier post , we showed a simple test to check if messages get lost in the ether while an upgrade is taking place. We would ideally like that cloud haskell also does not lose messages while it upgrades our code from one version to the next. In the worst case, we could make do without this requirement…
We can spawn multiple processes on a single node. Both erlang and cloud-haskell support this feature. Can we force a process to upgrade at any arbitrary point in time? Think about a scenario when a process is writing to a file/socket and acquiring lock to a shared resource (for example printing a file). We would not like the process to abruptly upgrade. So, how do we upgrade a process? We send an…
This blog would contain my thoughts on how to achieve hot code reloading in cloud haskell. Nothing too rigorous! Just my thoughts on a paper. A daily web-log documenting my thesis journey was originally published by Pankaj More at Pankaj More on February 06, 2014.
One of the problems that I am currently dealing with in my thesis is the following: How to make sure that the messages arriving during an upgrade don't get dropped? First , we have to make sure what happens in erlang. According to the erlang manual, erlang keeps 2 versions of the module in memory i.e old and current. When a module is upgraded, the old version is discarded processes running the old…