云风

我记得 sender 应该不能随便删的，因为服务可能会缓存地址，所以让那个 sender 负责拒绝服务更好。 我觉得再实现一套组网机构，应该不需要修改什么已有的代码，只是不用 cluster 模块就好了。skynet 现有的代码，也没有用到 cluster 。这个我觉得是可以独立出去的。

我觉得消息回传你可以考虑实现成 message queue 服务。在 mq 服务上创建一个 queue ，然后需要回传的消息 pub 回复消息进去，接收方可以 sub 这个 queue 。

lua 只支持一种 number 类型. 而在 pbc 中是按 protobuffer 协议来编码成 float 或 double 的。你的问题应该和 pbc 无关。

I know clearly, but I don't care.

是这个问题：https://github.com/ejoy/ant/pull/87 现在我手头没有环境做测试，所以没有支持好。关于检测 Mac 架构的部分，需要 @actboy168 在 luamake 上做一些工作。

另外，我觉得可以考虑退回去用 zlib 而不是 zlib-ng ，兼容性好一些，但会舍弃一些优化。

如果不需要特别为 mac 优化的话，我觉得可以关闭那些特有平台的 SIMD 分支。zlib-ng 应该也有保守的编译选项。或者退回 zlib 也不错。

这里不可以把 memcpy 改为变量赋值。因为这里计算出来的地址未必是对齐的，对不对齐的地址写数据，并非所有平台都是正确的。 另外，如果你用的平台 `malloc_usable_size` 行为和预期不一致，这里的修改也没有修复你说的问题。你只是把检查关掉了而已。 skynet 这里的代码使用的是 `je_malloc_usable_size` ，它的行为应该是确定的。

我试了一下上面的 test.c ，在我的系统上并没有报告错。 ``` $ gcc --version gcc (GCC) 13.2.1 20230801 $ gcc -O2 -o test test.c $ ./test size:32 usable_size:40 p:0x564c56de42c4 handle 1234 ```

我在 manjaro 上。而且 `size:32 usable_size:40` 就是不一致的。而且我认为 `malloc_usable_size` 的语义就是可以使用的内存，所以我认为你碰到了别的问题。 而且 `je_malloc_usable_size` 是 skynet 编译的 jemalloc 内部函数，它并不是 `malloc_usable_size` 不受 crt/libc 的影响。 如果这个 `usable_size` 实际被 crt 占用，那么你这么改也会破坏它。如果它其实是可用的，那么就是 crt 的误报，属于 gcc or crt 的...