主要观点：

• Async Rust 强大但使用和学习有难度，常需添加Send + Sync + 'static边界等，通过结构化并发和 per-core 线程异步运行时可避免。
• 'static边界导致需使用Arc等，破坏 Rust 核心部分，引发痛苦，而tokio的Runtime::block_on可无'static运行单个 future。
• 结构化并发是简单而影响深远的概念，能维护函数抽象、自动传播错误和清理资源，Rust 的futures结合结构化并发可自然绑定生命周期，无需'static。
• Rust 中结构化并发有动态和静态两种方式，动态适用于编译时不知 future 数量的情况，静态适用于已知数量的情况，都能避免'static生命周期。
• Send和Sync与 async Rust 相关，多线程工作窃取运行时tokio需Send，单线程 per-core 运行时可避免Send，共享状态时需Send但 futures 不必。
• 对工作窃取和 per-core 线程的粒度进行探讨，不同任务的工作差异及负载均衡水平未知，基准测试显示 Tokio 和 Glommio 在不同场景下性能各有优劣。
• 展示了使用 async Rust 无Send + Sync + 'static的代码示例，当前大多数流行的高级 Web 框架要求处理程序为Send + 'static，社区应支持 per-core 运行时和非Send + 'static futures。
• 结论认为应更关注“借用 + 并发”的解决方案，去除Send和'static要求可使 async Rust 更像同步 Rust，未来可关注相关提案和工作。

关键信息：

• tokio::spawn函数需'static边界，Runtime::block_on无'static边界。
• 结构化并发的好处包括维护函数抽象、自动传播错误和清理资源。
• Rust 中结构化并发的动态和静态方式及相关库。
• 多线程工作窃取运行时tokio需Send，单线程 per-core 运行时可避免Send。
• 对工作窃取和 per-core 线程的粒度探讨及相关基准测试。
• 无Send + Sync + 'static的 async Rust 代码示例及当前 Web 框架的限制。

重要细节：

• 'static边界使 future 可在后台运行，超出函数作用域，需Arc等绕过生命周期行为。
• 结构化并发中程序结构为树，无循环和悬空节点，能自动传播错误和清理资源。
• 动态结构化并发适用于编译时不知 future 数量的情况，如处理 incoming 连接，相关库有moro等。
• 静态结构化并发可利用 Rust futures 的独特属性，相关 primitives 有futures::join等。
• 单线程 per-core 运行时如glommio、monoio等使用io_uring实现高性能，与工作窃取运行时不同。
• 基准测试显示 Tokio 和 Glommio 在不同场景下性能差异，线程数、吞吐量、延迟等指标不同。
• 无Send + Sync + 'static的 async Rust 代码示例中，使用moro-local替代tokio的spawn，无需Arc和clone。
• 大多数流行的高级 Web 框架要求处理程序为Send + 'static，社区应支持 per-core 运行时和非Send + 'static futures。