我理解为什么需要重新实现可能阻塞当前线程的结构，例如Mutexand RwLock，以依赖于 futures/waker API，但为什么需要这样做Arc？
据我了解，标准上没有任何操作Arc是阻塞的，而在最新版本中，async_std::sync::Arc只是将std::sync::Arc.
这是否是面向未来的，以防未来的实现Arc需要依赖阻塞？
我应该在异步代码中使用哪一个，为什么？
重点是尽可能简化从std到 的过渡。async_std
板条箱的描述开头如下：
\n\n\n\n\n该板条箱提供了异步版本的
\nstd.
它的描述性特征之一是：
\n\n\n\n\n直观：与 stdlib 完全等同意味着您只需学习 API 一次。
\n
至于介绍它的博客文章，它清楚地提到这async_std意味着std尽可能地替代：
\n\n\n使用 时
\nasync-std\xe2\x80\x8b，所需的\xe2\x80\x99s 只需替换std\xe2\x80\x8b为async_std\xe2\x80\x8b，添加前奏\xe2\x80\x8b，然后撒上一些.await\xe2\x80\x8bs
（重点是我的）
\n\n考虑到所有这些，开发人员async_std选择重新导出std不需要适应的所有类型是有道理的async：用户不需要担心类型是否存在async，也不需要担心需要担心什么use。
| 归档时间： |
|
| 查看次数： |
554 次 |
| 最近记录： |