首先承认这个标题乍看之下很像 troll，但真的不是 troll；“避免使用”总的来说更接近 whenever possible 的意思。
另外，这篇 post 面向的主要是偏底层的、直接使用 system calls 或其 runtime wrapper（glibc）的开发者，最典型的比如 C/C++ 开发者。
其他语言的开发者通常因为要么 runtime “屏蔽”了这部分内容（如 Java）；要么 runtime 自身对这部分做了较大的抽象/改造（如 Golang），因此很难对此 post 提到的各种观点/做法产生共鸣。
FYI：自从工作后中文写作能力一直在退化，因此这篇文章如果存在语句不通顺或者用词不当的地方，烦请见谅。
signal 源自 Unix，后来成为 POSIX 标准的一部分，现在则被几乎所有的 *nix 系统支持。
signal 本质上是一种通讯机制，用于系统在某个事件（event）发生时通知某个进程（或线程）。
其实是 Jeff Preshing 的 Acquire and Release Fences Don’t Work the Way You’d Expect 这篇文章的笔记。
拿 learn-asio 这个项目练手时发现一个问题：learn-asio 依赖了 KBase，这两个项目都是我用 anvil 进行托管的，所以两个项目的 cmake 目录里各自有一份 compiler_*.cmake。
因为 compiler_*.cmake 提供的函数 apply_common_compiler_property_to_target() 默认使用了非常严格的属性，导致构建 asio 练手工程出现很多 warning 和静态分析的错误，所以为了省事我把 learn-asio 的这个函数做了宽松化处理。
考虑到 ASIO 的相当一部分组件（subset）已经进入了 C++ 20 Networking TS，未来再经过一些小调整之后成为标准库的一员基本板上钉钉。
那么提前熟悉一下 ASIO 也不是什么坏事，毕竟没准等到 C++ 23 的时候，coroutine, networking, executor 啥的都已经很完备了，谁都可以用 C++ 实现一些性能不差的 server-end 代码了（比如 RPC 框架？）。
不过和使用 Boost 类似，使用 ASIO 作为依赖库也不是一件容易的事情；毕竟自 modern C++ 元年至今都8年了，CMake 还在成为 de facto building system 的道路上挣扎，广泛接受的包管理依然不见踪影…
陈年老账就不再扯了，得益于 CMake 3.2 开始提倡的 taget-based properties 和 CMake 3.11 开始提供的 FetchContent module，我花了一些时间实现了一个基于 FetchContent 的 asio-cmake wrapper。
最近学习 MySQL 的过程中发现一些很坑的点，总结记录如下：