回复： gen_server互call回出现死锁吗？

[一平1]

如同时,A发B 在等B  B有回复了 才响应A     

 

------------------

一平   

 

------------------ 原始邮件 ------------------

发件人: "卓 一抗";

发送时间: 2013年1月29日(星期二) 下午5:06

收件人: "erlang-china"; "一平1";

主题: Re: gen_server互call回出现死锁吗？

为什么呢？不会出现 A进程 对B发出call请求， 同时B进程对A发出call请求，出现死锁？

[卓 一抗]

比如A进入一个消息处理过程，

A：
handle_call(other_message) ->
阶段1：进入过程.
阶段2：Call B
阶段3：退出过程.2


B:也一样
handle_call(other_message) ->
阶段1：进入过程.
阶段2：Call B
阶段3：退出过程.


当A和B同时进入阶段1时，由A先发出对B的call调用，然后B进入阶段2，向A发出call调用，这样不就死锁了吗？

[shiwei xu]

这个问题确实存在。尽管实际上没有死锁而是一方超时，但我认为这只是死锁的一种表现形态，因为毕竟业务没有真正完成。

2009年 ECUG 大会上，我的讲座 CERL: 谈谈“Boost.ASIO、Erlang与服务器编程”（见 http://ecug.qiniudn.com/lecturer/ ）详细描述过这个问题。

--
您收到此邮件是因为您订阅了 Google 网上论坛的“Erlang China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 erlang-china...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

--
许式伟

http://www.qiniutek.com/

[卓一抗]

原来如此，那我小心处理。

[Lihe Wang]

你这是为了造成死锁而造成死锁，实现际上你的这个例子其实是递归，不应该这样写。

但是如果非要这样写的话，handle_call的执行过程应该各自启一个新的进程进行延时操作，并且handle_call用noreply返回。这样A,B server就都不会阻掉，会处理新来的call消息，死锁就自然解了。同时，erlang自身默认的5秒超时，也使这种写法造成的死锁的代价变低了。

在 2013年1月30日上午9:20，卓 一抗 <zhuoy...@nibirutech.com>写道：