2009-07-02 23:53:25
我的梦想，你的梦想，我们大家的梦想，努力吧。the World of dream
2007年2月16日，the World of dream——梦想世界 诞生。
玛雅记录于2007年2月16日 22点33分
Lua Interface 的多核bug
[ 2008-11-04 23:25:41 pm | 作者: Maya ]
bug阿bug。。。
差不多去年年底的样子开始接触lua，主要都是在.net平台，所以看上了luainterface，使用也很方便，源码什么的都开放，近期在家里的双志强机器上跑程序发现活存在访问非法内存的问题，网上查之说是多核的一个bug，但是只有编译好的版本，并没有源码，还是想看看到底是什么原因造成的，也方便以后在对现有自己手上的版本做修正。
在luainterface的站点上看到几个解决方案，目前luainterface版本树上的应该已经修正了这个问题，不过作者引入了一个LuaBase的类，luaTable和LuaFunction都继承了LuaBase，然后在LuaBase里面写了关于析构的处理，我又不是很想把目前再用的版本替换成现在的版本树，毕竟不是release的。。。所以代码单独取出。
以上，在双C机器上跑了一天测试程序，没有在发现内存访问错误的问题。
差不多去年年底的样子开始接触lua，主要都是在.net平台，所以看上了luainterface，使用也很方便，源码什么的都开放，近期在家里的双志强机器上跑程序发现活存在访问非法内存的问题，网上查之说是多核的一个bug，但是只有编译好的版本，并没有源码，还是想看看到底是什么原因造成的，也方便以后在对现有自己手上的版本做修正。
在luainterface的站点上看到几个解决方案，目前luainterface版本树上的应该已经修正了这个问题，不过作者引入了一个LuaBase的类，luaTable和LuaFunction都继承了LuaBase，然后在LuaBase里面写了关于析构的处理，我又不是很想把目前再用的版本替换成现在的版本树，毕竟不是release的。。。所以代码单独取出。
~LuaTable()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public virtual void Dispose(bool disposeManagedResources)
{
if (!this.disposed)
{
if (disposeManagedResources)
{
interpreter.dispose(reference);
}
disposed = true;
}
}
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public virtual void Dispose(bool disposeManagedResources)
{
if (!this.disposed)
{
if (disposeManagedResources)
{
interpreter.dispose(reference);
}
disposed = true;
}
}
以上，在双C机器上跑了一天测试程序，没有在发现内存访问错误的问题。
关于Fluegelvon中引入的事件驱动
[ 2008-04-19 22:44:46 pm | 作者: Maya ]
最近重新看了下Fluegelvon以前的实现，因为基础的底层代码已经是在一年半以前完成的了，所以整个体系架构上有太多的不完善，前段时间引入了消息队列来更好的控制控制系统内部的消息通讯。因为重新看了底层的实现，因为有两条主要的消息处理线程，都是while(isRun){...}这种方式来实现的，总觉得很别扭，虽然很多服务器端系统在设计的时候基本上都这么用，起码看到过的都是这样。总感觉不好。。。
最近忽然想起来在一年半以前开始设计Fluegelvon整个结构的时候，曾经想过整个系统使用事件来驱动整体的运作，每一个外围的模块最终都注册到整个事件驱动内部来统一调度，因为一年多的事件大部分时间都在调优整个系统的通讯模型，所以这一块就一直没有管，想法也就这么放下了。最近正好底层的模型基本上都已经完成的差不多了，开始调整脚本类的内容，所以决定重新拾起这个“事件驱动”模型。
其实说起来这个模型本身也是很简单的一个结构，运作机制是Timer+Event，Timer提供了类似while(isRun){...}这种结构，Event提供了一个触发的机制。这样一个完整的运行模式就出现了。首先系统在启动时开启一个Timer按照一定的频率唤醒（比如10Hz），当这个Timer唤醒以后会马上触发所有等待执行的事件，这些等待事件都存储在EventList当中，实际上这个事件列表只记录在Timer沉睡的这段时间里面系统都触发了那些事件。
以上只是一个很混乱的思维的总结，目前还没有构思出一个很完整的实现，暂时的想法是在Timer当中注册所有的事件，然后每一次唤醒都检查事件是否需要激活，但是又考虑到效率的问题。还要继续的思考如何实现，继续修改腹稿。。。
最近忽然想起来在一年半以前开始设计Fluegelvon整个结构的时候，曾经想过整个系统使用事件来驱动整体的运作，每一个外围的模块最终都注册到整个事件驱动内部来统一调度，因为一年多的事件大部分时间都在调优整个系统的通讯模型，所以这一块就一直没有管，想法也就这么放下了。最近正好底层的模型基本上都已经完成的差不多了，开始调整脚本类的内容，所以决定重新拾起这个“事件驱动”模型。
其实说起来这个模型本身也是很简单的一个结构，运作机制是Timer+Event，Timer提供了类似while(isRun){...}这种结构，Event提供了一个触发的机制。这样一个完整的运行模式就出现了。首先系统在启动时开启一个Timer按照一定的频率唤醒（比如10Hz），当这个Timer唤醒以后会马上触发所有等待执行的事件，这些等待事件都存储在EventList当中，实际上这个事件列表只记录在Timer沉睡的这段时间里面系统都触发了那些事件。
以上只是一个很混乱的思维的总结，目前还没有构思出一个很完整的实现，暂时的想法是在Timer当中注册所有的事件，然后每一次唤醒都检查事件是否需要激活，但是又考虑到效率的问题。还要继续的思考如何实现，继续修改腹稿。。。
1