Bab

免责声明：这个包是实验性的，使用了相当多的不安全代码块。它不适合生产环境。如果您发现错误 / UB / 竞态条件，请提交问题。Loom 测试是一个待办事项。

您是否曾想过构建自己的总线？没有？那么现在您可以做！

Bab，简称“构建总线”，是一个库，旨在为您应用程序的消息总线提供基础组件。其核心组件包括

• 一个异步 BufferPool，允许在启动后快速分配和回收缓冲区，而不需要任何内存分配。根据当前的 API，通常不需要直接与 BufferPool 交互。
• Packet，一个消息的处理句柄。数据包由缓冲区的一个区域支持，多个数据包可以由同一个缓冲区支持。缓冲区引用由系统管理 - 当缓冲区的所有引用都被丢弃时，它将自动释放回池中。
• 对于创建和发送消息，使用 Writer 和 WriteFlusher。编写者会在自动获取的缓冲区上为消息预留空间。由编写者服务的 WriteFlusher 将消息批量提供给调用者，例如在 TCP 套接字上刷新，批量和刷新节奏完全由您控制。每个写入的消息也会以 Packet 的形式返回给调用者，以便在需要时在本地应用程序中循环。
• 对于接收传入的消息，使用 Framer，它允许您将字节写入到一个暂存区域，以便将其框架到 Packet 中供您的应用程序消费。

Bab 有一些偏见并且有点奇怪 - 它使用线程局部优化，并且通常假设您的应用程序是线程每核心。它的未来（例如，由 BufferPool::acquire 返回的）是 !Send，因此不能与像 Tokio 的多线程执行器这样的工作窃取执行器一起使用。例如，您可以使用 Tokio 的 LocalSet 和 futures-executor 的 LocalPool。

数据包也可以是!发送。要在线程之间发送数据包，必须调用其上的数据包::send方法以获取一个发送数据包。然后在接收线程上调用发送数据包::receive将其转换回数据包。

路线图

• 添加LocalWriter - Writer的!发送版本。
• 对BufferPool / BufferPtr的线程安全接口？
• Loom测试

为什么？

有两个与bab（批处理和线程局部优化）略有相关的问题，激励了bab的发展。

批处理

批处理是bab中的一个常见主题，但我最喜欢的例子是在Writer / WriteFlusher中。多个线程上的多个写入者可以写入相同的基本缓冲区，所有这些消息（可能跨越多个缓冲区）可以单个（相当昂贵的）O(1)操作发送到刷新器。请注意，这里批处理中发生的不仅仅是刷新 - 单个缓冲区可以包含多个消息，因此您可以非常自然地将多个消息打包到一个单个的输出数据包中（想象一下您正在使用UDP），这可以帮助您更好地利用网络的MTU（巨型帧，有人吗？）。

线程局部优化

在我的x86 System76 Darter Pro笔记本电脑上（这是免费的产品推广吗？），criterion表明，无争用的AtomicUsize::fetch_add花费约5.5纳秒，而一个非原子的usize::wrapping_add花费约280皮秒（1-2个时钟周期？），两者都设置了核心亲和力。因此，在我们的微基准测试中，原子增加比其非原子对应物昂贵一个数量级，即使受影响的缓存行仅从同一核心访问。并发数据结构肯定不是免费的。