The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet. Your reply message has not been sent.
Your post was successful
 |
From: 老范 <fanyun2...@gmail.com>Date: Fri, 3 Jul 2009 08:47:19 -0700 (PDT)
Local: Fri, Jul 3 2009 11:47 am
Subject: 恶狼战役：getTime() 的容错性问题
在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
debug 功能后， 系统就崩溃了。
发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
战斗结束了，就把 时钟表删掉了。
这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
对于getTime 做了try 处理，提高容错性。 解决了这个问题。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Zoom.Quiet" <zoom.qu...@gmail.com>Date: Sat, 4 Jul 2009 00:13:23 +0800
Local: Fri, Jul 3 2009 12:13 pm
Subject: Re: [erlang-china:2189] 恶狼战役：getTime() 的容错性问题
2009/7/3 老范 <fanyun2 ...@gmail.com>: > 在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。
嗯嗯嗯,其实,先写个期望大家怎么调用的伪代码, 用故事叙述一下,整个战场的逻辑, 就容易看出哪儿应该有问题了,,,, 现在,就只能多测试了,,,
> 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表 > debug 功能后， 系统就崩溃了。 > 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
> 战斗结束了，就把 时钟表删掉了。
> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
-- http://zoomquiet.org 人生苦短,Pythonic!-) Time is unimportant, only life important!
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: 老范 <fanyun2...@gmail.com>Date: Sat, 4 Jul 2009 00:17:22 +0800
Local: Fri, Jul 3 2009 12:17 pm
Subject: Re: [ECUG:456] Re: [erlang-china:2189] 恶狼战役：getTime() 的容错性问题
这个问题的诊断和处理，让我越发 “并行计算” 的复杂度有了深刻的认识。 在顺序环境中，这都是没必要考虑的问题。
并行环境中， 时序的处理非常重要。 都要仔细琢磨。
Regards
老范
2009/7/4 Zoom.Quiet <zoom.qu...@gmail.com>
> 2009/7/3 老范 <fanyun2 ...@gmail.com>: > > 在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。 > 嗯嗯嗯,其实,先写个期望大家怎么调用的伪代码,
> 用故事叙述一下,整个战场的逻辑,
> 就容易看出哪儿应该有问题了,,,,
> 现在,就只能多测试了,,,
> > 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
> > debug 功能后， 系统就崩溃了。
> > 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
> > 战斗结束了，就把 时钟表删掉了。
> > 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
> > ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
> > 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
> --
> http://zoomquiet.org 人生苦短,Pythonic!-)
> Time is unimportant, only life important!
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: Max Fung <honeygigear...@gmail.com>Date: Sat, 4 Jul 2009 00:42:24 +0800
Local: Fri, Jul 3 2009 12:42 pm
Subject: Re: [erlang-china:2189] 恶狼战役：getTime() 的容错性问题
下载r190
从源程序上，都太过于依赖ets。
例如：
worldclock.erl
battle_timer 就可以不使用 ets
在start的时候，直接出个线程就好了，
请见附件
【注意，我只是举个例子来写，没有完成worldclock】
现在程序中，很多的ets都可以不要的。
ets有它使用的地方，如果只是作为单纯的变量传递，请尽量不要使用。
在erlang一切都是process ，忘了java，忘了c，忘了……吧
尽量用erlang的世界观去解决问题。
2009/7/3 老范 <fanyun2...@gmail.com>
> 在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。 > 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
> debug 功能后， 系统就崩溃了。
> 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
> 战斗结束了，就把 时钟表删掉了。
> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: Max Fung <honeygigear...@gmail.com>Date: Sat, 4 Jul 2009 00:47:18 +0800
Local: Fri, Jul 3 2009 12:47 pm
Subject: Re: [erlang-china:2189] 恶狼战役：getTime() 的容错性问题
另外，时间控制，强烈推荐使用 timer 模块，具体使用查api吧 :)
2009/7/4 Max Fung <honeygigear...@gmail.com>
> 下载r190 > 从源程序上，都太过于依赖ets。
> 例如：
> worldclock.erl
> battle_timer 就可以不使用 ets
> 在start的时候，直接出个线程就好了，
> 请见附件
> 【注意，我只是举个例子来写，没有完成worldclock】
> 现在程序中，很多的ets都可以不要的。
> ets有它使用的地方，如果只是作为单纯的变量传递，请尽量不要使用。
> 在erlang一切都是process ，忘了java，忘了c，忘了……吧
> 尽量用erlang的世界观去解决问题。
> 2009/7/3 老范 <fanyun2...@gmail.com>
>> 在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。
>> 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
>> debug 功能后， 系统就崩溃了。
>> 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
>> 战斗结束了，就把 时钟表删掉了。
>> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
>> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
>> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: 老范 <fanyun2...@gmail.com>Date: Sat, 4 Jul 2009 00:58:55 +0800
Local: Fri, Jul 3 2009 12:58 pm
Subject: Re: [erlang-china:2192] Re: 恶狼战役：getTime() 的容错性问题
感谢Max 的意见。 首先我自己也对于使用ets 做数据传递觉得有点那个。 但是没想到好办法。
看了Max 的代码和邮件， 觉得有些启发。 但是在erlbattle 的具体场景中可能还是有些问题需要进一步解决。
1. 这个worldclock 和timer 不是一回事。 他不是一个定时器。准确来讲是一个节拍器。
表明战场一个一个节拍的往下走。未来系统进一步优化的时候，希望在不同处理能力的机器上， 在每个节拍给决策程序提供的“计算周期” 是一样的。
2. Max 程序中用消息方式从worldclock 中提取出当前时间。
这样的话，如果需要查询时间的“决策进程” 频繁，恶意的向worldclock
发时间请求消息，会造成时间没法往下走的情况，也可以堵塞对手查询时间的功能。让对手不能及时知道当前时间。
现在使用的时钟表， 战场表， 双方下一步指令队列表 都有这种并行查询的需求。用消息来问恐怕有点不妥。
Regards
老范
2009/7/4 Max Fung <honeygigear...@gmail.com>
> 下载r190 > 从源程序上，都太过于依赖ets。
> 例如：
> worldclock.erl
> battle_timer 就可以不使用 ets
> 在start的时候，直接出个线程就好了，
> 请见附件
> 【注意，我只是举个例子来写，没有完成worldclock】
> 现在程序中，很多的ets都可以不要的。
> ets有它使用的地方，如果只是作为单纯的变量传递，请尽量不要使用。
> 在erlang一切都是process ，忘了java，忘了c，忘了……吧
> 尽量用erlang的世界观去解决问题。
> 2009/7/3 老范 <fanyun2...@gmail.com>
>> 在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。
>> 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
>> debug 功能后， 系统就崩溃了。
>> 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
>> 战斗结束了，就把 时钟表删掉了。
>> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
>> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
>> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
From: "Zoom.Quiet" <zoom.qu...@gmail.com>Date: Sat, 4 Jul 2009 01:21:45 +0800
Local: Fri, Jul 3 2009 1:21 pm
Subject: Re: [erlang-china:2194] Re: 恶狼战役：getTime() 的容错性问题
2009/7/4 老范 <fanyun2 ...@gmail.com>: > 1. 这个worldclock 和timer 不是一回事。 他不是一个定时器。准确来讲是一个节拍器。
> 表明战场一个一个节拍的往下走。未来系统进一步优化的时候，希望在不同处理能力的机器上， 在每个节拍给决策程序提供的“计算周期” 是一样的。
是也乎,而且这个节拍器是可以调节的,比如说,慢到 3秒钟一次,以便可以明白的看到每次双方的出击; 也可能 2秒一次,以便加速自动化测试... 更加重要的是,将来为了分布式运行,必须根据网络状态,自动进行同步降速,以便双方的EB世界时间是同步的... > 2. Max 程序中用消息方式从worldclock 中提取出当前时间。 > 这样的话，如果需要查询时间的“决策进程” 频繁，恶意的向worldclock > 发时间请求消息，会造成时间没法往下走的情况，也可以堵塞对手查询时间的功能。让对手不能及时知道当前时间。 > 现在使用的时钟表， 战场表， 双方下一步指令队列表 都有这种并行查询的需求。用消息来问恐怕有点不妥。
嗯嗯嗯,核心原理就是: - 时钟和战场 在EB 中应该是中立的,不可影响的: + 时钟就是授时,统一行动节奏 + 战场就是记录进程,核对各双血状态 - 所以,得反过来? + 统一向双方定期推信息 + 或是向一个消息总线通报信息,由双方战士决定何时查询?
> Regards
> 老范
> 2009/7/4 Max Fung <honeygigear...@gmail.com>
>> 下载r190
>> 从源程序上，都太过于依赖ets。
>> 例如：
>> worldclock.erl
>> battle_timer 就可以不使用 ets
>> 在start的时候，直接出个线程就好了，
>> 请见附件
>> 【注意，我只是举个例子来写，没有完成worldclock】
>> 现在程序中，很多的ets都可以不要的。
>> ets有它使用的地方，如果只是作为单纯的变量传递，请尽量不要使用。
>> 在erlang一切都是process ，忘了java，忘了c，忘了……吧
>> 尽量用erlang的世界观去解决问题。
>> 2009/7/3 老范 <fanyun2...@gmail.com>
>>> 在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。
>>> 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
>>> debug 功能后， 系统就崩溃了。
>>> 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
>>> 战斗结束了，就把 时钟表删掉了。
>>> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
>>> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
>>> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
-- http://zoomquiet.org 人生苦短,Pythonic!-) 过程改进乃是催生可促生靠谱的人的组织! (PE keeps evolving organizations which promoting people be good!)
You must Sign in before you can post messages. You do not have the permission required to post.
|
|
|
|
