- 主题:异步stream的问题
没试过自己实现，仅仅根据印象的看法，如下：
实现Stream，前提是实现Future，如果你实现了Future和Stream，又符合标准的话，我觉得，就可以被别的异步运行时操作，因为这些异步运行时本来就应该支持操作Stream
【 在 chunhui 的大作中提到: 】
: 各位，有个stream的问题，有点不明白。
: 我想给自己的一个结构实现stream特性。但是异步运行时是有很多不同的实现对吧？那是否这些实现，都可以支持我这个结构体的stream？stream的异步运行时和async/.await这一套是同一个运行时来驱动的么？我看介绍他们都是future，都有pool，pending之类的。
: 或者这么说，我想实现一个异步的运行时，其行为和通常的稍微不同，所以只能自己实现。那么我自己实现的这个运行时，是否可以支持通常的stream？
--
FROM 1.202.157.*
似乎tokio的网站首页有个教程链接，挺详细那种
tokio，std，smol 应该都能参考
印象中smol性能最好，tokio最易用，应该都可以参考
我一般图简单用tokio
但去年有个程序开发任务，很关注性能，就是响应一次底层触发消息，要在小于3us的时间内传递完当前消息，重新进入就绪。让我第一次发现异步似乎不能完全替代同步任务，最后还是同步任务（再配合魔改驱动）才能解决问题
【 在 chunhui 的大作中提到: 】
: 是这个道理。初步认为应该是可以的。有没有运行时实现相关的资料给推荐一下？我试试
【 在 AlphaO 的大作中提到: 】...
--
FROM 124.64.19.*
只要是非实时系统，大概就都不行，换成C和C++更难搞定
一次消息16KB，相邻两次消息间隔不定，最长约100us，最短约4~5us
用异步任务就会经常错过下一次消息，总怀疑是异步运行时的问题，而且怀疑异步IO会频繁触发系统调用，导致内核态/用户态切换，存在一个不确定开销。 不知道怀疑的点是否合适
【 在 chunhui 的大作中提到: 】
: 我去看看
: 你这种实时性要求高的，貌似rust这种没有实时抢占全靠自觉放弃cpu的合作多任务比较麻烦。
--
修改:AlphaO FROM 1.202.157.*
FROM 1.202.157.*
嗯，已经是分离的架构，类似下面语句不断循环
if let Ok(size) = bufreader.read(&mut msg, MAX_READ_LENGTH).await {
mpsc_handle_tx.try_send(msg).unwrap();
}
只要收到msg，就发给其他线程处理，然后read.await下一帧
但实际上，两次await的间隔（前一个await完成 —— 当前await开始），有时就会超过4us（虽然不是很频繁，平均100次能发生1-3次），表现就是，下一帧会丢一些字节
但仅仅把await改成同步，则总体上能相对改善一些，虽然还是不能彻底解决。（解决需要改一下架构，同时各个环节全面优化，很琐碎）
【 在 NewMonk 的大作中提到: 】
: 将处理消息任务和接收消息暂存任务分开，是否能解决丢失消息的问题？
: 既然处理消息的时长不定，就只能先暂存消息了。
:
--
FROM 1.202.157.*
是的，我摸索感觉，瓶颈主要可能是CPU不只专门接收。仅从代码看，接收1次完毕后，立刻用mpsc发出去，它理应立刻准备去接下一帧。但实际上我感觉——在异步await下——CPU此时也许会进行系统调度，比如后台其他任务突然占用该CPU一定时间等等。 其实如果无操作系统，或者实时系统配置一下，估计不会有问题
【 在 chunhui 的大作中提到: 】
: 正在执行的其他任务不能保证及时释放cpu。得一直等到当前任务完成，运行时才有机会去执行到来的消息。如果当前任务消耗时间超过100us。那肯定会丢消息。 或者说不需要当前任务时间长，只要它正赶上消息到来的时间没处理完，那就会丢消息。
: 可以考虑轮询消息？这样会浪费cpu。
--
FROM 1.202.157.*
这个思路尝试过，但对操作系统有要求，而对通用的windows和常用linux变种则行不通，因为这些通用操作系统，为了充分利用硬件，在线程调度方面有内置的优化策略，这种优化调度会动态打破线程和任务的绑定关系。例如，无法将一个核指定为仅仅运行1个特定任务而不运行其他，哪怕强行指定其他用户进程对该核的完全不亲和，但内核进程不归用户控制，还是会征用该核
【 在 NewMonk 的大作中提到: 】
: 不知道下面这个想法是否可以解决问题：
如果硬件是多核的，可以考虑再把接收消息暂存任务放到一个线程中，处理消息放到另一组...
--
FROM 114.246.94.*
确实有点这个意思，除了dpdk是利用以太网，我是利用U3。技术途径看着也差不多，数据全程零拷贝，恰好是Rust擅长的。最后软件要在windows上用，因为可能的使用者还是最习惯windows
【 在 chunhui 的大作中提到: 】
: 你这个和dpdk类似。它可以做到独占核心。不过你的环境是嵌入式把？如果你可以不用os，可能比折腾这些更简单。
:
--
FROM 1.202.157.*
哪里，过奖了，如果用c/cxx、c#肯定搞不到性能这么快和好，可以说是95%得益于Rust工具链
【 在 chunhui 的大作中提到: 】
: 厉害！
--
FROM 1.202.157.*
赞
【 在 chunhui 的大作中提到: 】
: rust是个好东西。我也想了解了解。
--
FROM 1.202.157.*