Hellclient 社区

jarlyyn

跑了一周内存泄漏/稳定性测试，目前很稳定。

考虑在解决proxy问题后，接入python玩玩。

jarlyyn

脚本基本跑通了。还是稳定性和内存泄漏测试。

整理了下构架

jarlyyn

好消息:clearscript对接很快，主体功能已经进入王东伟，机器能正常跑。
坏消息：开了clearscript，没法开裁剪了，项目进一步膨胀到了50多m+50多m。

只能说，clearscript还是上个jit时代的产品。很强，但在很多场景下，不是那么合适。

jarlyyn

目前已经把基本工作做完，开始嵌入v8的工作。

然后发现比较蛋疼的地方。

嵌入v8后，主程序大概22mb，v8的so大概57mb,可以upx到35m左右，也就是一个操作系统大概是 60mb左右。

对比hellclient go版本是30多mb/13mb(upx后)一个版本。

有点夸张。

jarlyyn

发现问题了

是UI库alalonia在mac下的一个bug

目前已经升级UI库版本，重新打包，麻烦您重新下载，看看是否解决问题。

jarlyyn

@kele 我check一下

jarlyyn

然后一些关于锁的优化的细节。

这两天把自动机部分重做了，有点累倒了。休息下想象关于锁竞争的问题。

之前做hellclient时考虑的是脱耦，隔离，每个组件通过总线进行通信。所以锁是基于数据的，内部(私有)访问不加锁，总线(公开)访问加锁。

这次准备把锁加到入口。

也就是在发起调用的位置加锁，一次只允许一次调用加锁。数据本身保持无锁。

根据实际的内部访问复杂度，感觉这种调度更合理点。

jarlyyn

在目前的原型代码里测试了下，再对c#进行了一些调研。

只能说，没有银弹。

c#里还是只能用 lock/SemaphoreSlim的锁，或者ActionBlock的类Channel方法来处理数据竞争。

想象也是，go这种从以发明就走并发路线语言，没道理不用最优的方案的。

当然，既然是重构，本身这个问题还是有能改善的。

就是把我hellclient代码里在不同组件里各司其职的多个锁，优化一个World一个统一锁，然后再可能引起并发的入口函数处统一加锁，不要锁满世界乱飞。

jarlyyn

先把代码总体架构给组织理顺了。

之前的代码走的按功能按组件划分。现在将每个模块分了3个层，按层整理代码。

这样的优点是有测试的可能。hellclient本身因为都是散布的组建，其实很难做分块的测试。

同时找代码也更方便一点。

毕竟hellclient是从0开始长起来的，互相之间的依赖肯定更重。

hellclient.net是重构项目，能花时间考虑怎么组织和布局。

jarlyyn

此外.net版本还会尝试精细的经常控制。

go 版本过于然用go协程，然后锁控制，后期有点失控。