erlang driver和热部署（重要）

erlang的热部署包括2个方便的 beam(.beam)级别的和driver(.dll .so)级别的. beam级别的就简单。但是driver级别的就相对复杂很多。

先看下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进程 管理这个port  由这个process 代理所有的请求和响应。这种情况下 更换driver就很简单 因为系统中只有一个driver的使用者， 非常容易作load unload reload的操作。而且在process异常终止的时候 emulator自动会释放driver的资源。

这个回答了我许久以来困惑我的问题： 为什么erlang kernel里面的file->file_server, code->code_server这样的架构， 终于在这个时候真相大白。看来erlang比我们考虑的要周道。

有兴趣的同学可以参考下release_handling的实现，相信会对hot deployment 有很深的理解。