在实际应用中，搞清楚process和其所拥有的socket之间的天生绑定关系，在写代码时就能小心避免错误。
Erlang中有不少这样的情况，比如process和其创建的ets表，也是一种从属关系，control process
销毁后，其ets表也不存在了。

另外，我认为socket还是不应该通过函数的参数来传递，即使其control process在传递完socket后依
旧存在，但是这样做还是不安全的，无法断定control process何时被kill。正确的方法应该是使用
gen_tcp中的controlling_process(Socket,Pid) -> ok|{error,eperm}函数，使得socket更换
其control process,这样就达到使其他process来代替原先的process控制特定socket的目的。从这个
函数也可以看出一点“socket属于它的control process”的端倪来。

和外界打交道的地方，也就是可能引入‘side effect’的地方，与其在系统外由外部的机制来保证处理的完整性，还不如仅仅通过一个单一的进程——“control process”来控制，其余进程通过与这个“control process”通讯，来获得对于资源的访问。

这貌似多此一举，实则不然。因为，一方面这“屏蔽”了外界系统对于并发支持的差异，将“并发/并行”的复杂性限制在 Erlang 的框架之内，通过“进程间通讯”的方式解决，从而得以最大限度的“无锁化”。令一方面，也简化了失效处理的策略，一旦失效，直接 kill 掉再重启就行，无须担心多个进程之间共享同一个资源，而导致的复杂锁定情况。

因此，这也可以说是“Erlang无锁化思想在其他问题上的延伸”。

比较 pitfall 的是，竟然没有文档提到 socket 与 creator process 的关系是： socket “属于”它的 control process 。毕竟，这与大家所熟悉的观念还是很不相同的。