erlang的热部署包括2个方便的 beam(.beam)级别的和driver(.dll .so)级别的. beam级别的就简单。但是driver级别的就相对复杂很多。
先看下erl_ddll的说明:
这个回答了我许久以来困惑我的问题: 为什么erlang kernel里面的file->file_server, code->code_server这样的架构, 终于在这个时候真相大白。看来erlang比我们考虑的要周道。
有兴趣的同学可以参考下release_handling的实现,相信会对hot deployment 有很深的理解。
先看下erl_ddll的说明:
-
Loading and reloading for code replacement
-
This scenario occurs when the driver code might need replacement during operation of the Erlang emulator. Implementing driver code replacement is somewhat more tedious than beam code replacement, as one driver cannot be loaded as both "old" and "new" code. All
users of a driver must have it closed (no open ports) before the old code can be unloaded and the new code can be loaded.
The actual unloading/loading is done as one atomic operation, blocking all processes in the system from using the driver concerned while in progress.
The preferred way to do driver code replacement is to let one single process keep track of the driver. When the process start, the driver is loaded. When replacement is required, the driver is reloaded. Unload is probably never done, or done when the process exits. If more than one user has a driver loaded when code replacement is demanded, the replacement cannot occur until the last "other" user has unloaded the driver.
Demanding reload when a reload is already in progress is always an error. Using the high level functions, it is also an error to demand reloading when more than one user has the driver loaded. To simplify driver replacement, avoid designing your system so that more than than one user has the driver loaded.
这个回答了我许久以来困惑我的问题: 为什么erlang kernel里面的file->file_server, code->code_server这样的架构, 终于在这个时候真相大白。看来erlang比我们考虑的要周道。
有兴趣的同学可以参考下release_handling的实现,相信会对hot deployment 有很深的理解。