exch4nge

虽然没在工作中用过 Rust ，不过个人觉得 Rust 优势在团队开发的时候，review 别人的代码变得更简单，你能相信代码没有诡异的多线程安全问题，没有内存泄漏等，相对来说看 C++ 就得考虑前面几种问题
即使有很多年 C++ 经验，复杂需求下的写出内存安全还是有些难度的，难免会踩一些坑
看好 Rust ，不过国内岗位太少

gdb 显示的信息里 address 是 prism::json::fromJsonString<dv_common_config>
所以 dv_common_config 是什么？是 product_config 吗？

1. bear 后面应该可以接多个 make 命令
2. 上面的不行，根上也可以建一个 makefile ，内容是执行子目录的 make 命令

win10 store 里的 app 之前是沙箱隔离的，现在大部分不是了。此外 Sandboxie 可以用来隔离一部分软件。或者用 Windows Sandbox 一次性沙箱。

vscode 断下来后，默认会显示多个线程吧 https://code.visualstudio.com/docs/cpp/cpp-debug#_multithreaded-debugging
要是 linux 建议先学 gdb

建议先用一般思路实现一版本，然后再做这种设计，比对性能。性能这东西基本都得靠实践。
一般思路：找个线程池实现，如 folly 的 cpu thread pool ，内存分配用 jemalloc 之类的

绑核了就 spin 查消息吧，用什么 zeromq ，io 唤醒得有多慢。
单个模块一个线程/核心？这么设计会更快么？不会有某个模块处理慢么，不加点线程/核心？
切换线程可能把 cache 都丢了，有些情况下还不如一个线程跑完整个处理

可能跟 block size(?) 之类的分区参数有关系？

@Chipmunker 是 node
@ #14

vscode ssh 上去的时候看 OUTPUT （输出）窗口会有详细的日志，第一步分析日志发现直接报一些系统版本有关系的错误，我的系统是 CentOS 7 所以提示的是 glibc 跟 cxx 版本过低

找到日志里的一个路径，是 code-xxxxxxxxxxxxxxx 结尾的，上机器找到这个目录，这个文件是个 script ，打开会发现有检查 /tmp/xxxxxxxxxxxx 这个路径有文件就 skip os version check 之类的操作，手动创建这个文件

然后一般这个目录的上一级目录有个 node 可执行文件，这个是需要 patch 的，我用了自己安装的 glibc 跟 cxx 的路径，用 patchelf 打了补丁，打完执行 ./node 检查看看能否运行

再次尝试用 vscode ssh 上去（每次先退 vscode 再把相关进程都 kill 掉），还是会有错误，仔细看日志发现，某个可执行文件执行不了，报错里提到也没找到 musl 什么的，然后自己再安装了 musl

然后再次尝试 vscode ssh 上去，就可以了，右下角会弹出警告框，但是功能没问题。

如果你能直接升级操作系统的 glibc 之类的版本的话，那应该更简单，不过我没试过，也在网上看到很多升级 glibc 后遇到很多问题的事情，就没敢动，只是找个其它位置安装的。