如何看待七牛 CEO 许式伟开源的 Cerl？ 第1页

多谢邀请。我是当事人，不便回答。我会关注此问题，希望能够看到更多关于 cerl 本身的讨论。同时也希望 erlang 社区能够多些包容，不要看到有人指出 erlang 某个地方的缺陷就开始撒泼。如果你们的技术探讨能够让我学习到 erlang 里面某些我不太了解的东西，能够让我收回对 erlang 的评价，这也许是维护 erlang 的更好方式。

看了下目前几个比较活跃的回答，做如下答复：

：Erlang有没有避开锁，这个不同人视角不一样，结论不同，我不想纠缠于锁的定义，问题本身已经阐述清楚就行。

认为，我提的死锁问题本质上是设计不当，不应该让 A 和 B 相互依赖，而不是 Erlang 的问题。这个观点粗听有道理，但其实经不起推敲。在软件架构设计上，不要让两个模块相互引用（A import B，而 B 又 import A），这属于常识。但这仅仅是从代码结构上来讲的静态依赖。从运行时来说，A 与 B 必然会出现相互作用的情况。比如 A 依赖 B，但是 B 可能要求 A 实现一个 callback 或者 interface，在 B 里面调用 callback 或 interface 里的某个方法时，就是 B 反作用于 A 的情况。如果觉得这样的描述比较抽象，我们也可以举几个实际的例子。比如我们有一个 Master 需要分配很多任务给多个 Worker 实例。一种典型实现是 Master 给所有 Worker 推送任务，然后 Worker 做完任务时通知 Master 某个任务完成（你可以把这个完成通知想象成callback）。这里就出现了 Master 和 Worker 相互作用的情况。所以代码结构没有循环依赖，并不代表两个服务不会相互作用（互发消息），这完全是两个概念。而一旦出现这种相互作用的场景，就会出现死锁（表现为 timeout），打破这种死锁的唯一办法是 Master 或 Worker 有一个人需要把 call 改为 cast（同步代码转为异步）。为什么这个问题在 Erlang 里面存着而 CERL 和 Golang 里面不存在，是因为 CERL 和 Golang 里面服务器是多进程（这里进程是指执行体，CERL 里面叫 Fiber，Golang 里面叫 goroutine），而 Erlang 里面服务器是单进程的（好吧，可能又有人要和我纠缠说 Erlang 里面的服务器明明不是单进程的么，对此我只能表示无语）。

今天比较忙，暂时只回答一个问题。

---

看了一遍今天新增的 thread，我决定取消该问题的关注，不再参与该话题的讨论。各位玩得开心。

---