- 主题:异步stream的问题
-   各位,有个stream的问题,有点不明白。
 
 我想给自己的一个结构实现stream特性。但是异步运行时是有很多不同的实现对吧?那是否这些实现,都可以支持我这个结构体的stream?stream的异步运行时和async/.await这一套是同一个运行时来驱动的么?我看介绍他们都是future,都有pool,pending之类的。
 
 或者这么说,我想实现一个异步的运行时,其行为和通常的稍微不同,所以只能自己实现。那么我自己实现的这个运行时,是否可以支持通常的stream?
 --
 FROM 117.133.52.*
 
- 没试过自己实现,仅仅根据印象的看法,如下:
 
 实现Stream,前提是实现Future,如果你实现了Future和Stream,又符合标准的话,我觉得,就可以被别的异步运行时操作,因为这些异步运行时本来就应该支持操作Stream
 
 
 【 在 chunhui 的大作中提到: 】
 : 各位,有个stream的问题,有点不明白。
 :  我想给自己的一个结构实现stream特性。但是异步运行时是有很多不同的实现对吧?那是否这些实现,都可以支持我这个结构体的stream?stream的异步运行时和async/.await这一套是同一个运行时来驱动的么?我看介绍他们都是future,都有pool,pending之类的。
 : 或者这么说,我想实现一个异步的运行时,其行为和通常的稍微不同,所以只能自己实现。那么我自己实现的这个运行时,是否可以支持通常的stream?
 --
 FROM 1.202.157.*
 
- 是这个道理。初步认为应该是可以的。有没有运行时实现相关的资料给推荐一下?我试试
 【 在 AlphaO 的大作中提到: 】
 : 没试过自己实现,仅仅根据印象的看法,如下:
 : 实现Stream,前提是实现Future,如果你实现了Future和Stream,又符合标准的话,我觉得,就可以被别的异步运行时操作,因为这些异步运行时本来就应该支持操作Stream
 :
 --
 FROM 221.216.116.*
 
- 似乎tokio的网站首页有个教程链接,挺详细那种
 tokio,std,smol 应该都能参考
 印象中smol性能最好,tokio最易用,应该都可以参考
 我一般图简单用tokio
 
 
 但去年有个程序开发任务,很关注性能,就是响应一次底层触发消息,要在小于3us的时间内传递完当前消息,重新进入就绪。让我第一次发现异步似乎不能完全替代同步任务,最后还是同步任务(再配合魔改驱动)才能解决问题
 
 
 【 在 chunhui 的大作中提到: 】
 : 是这个道理。初步认为应该是可以的。有没有运行时实现相关的资料给推荐一下?我试试
 【 在 AlphaO 的大作中提到: 】...
 --
 FROM 124.64.19.*
 
- 我去看看
 
 你这种实时性要求高的,貌似rust这种没有实时抢占全靠自觉放弃cpu的合作多任务比较麻烦。
 【 在 AlphaO 的大作中提到: 】
 : 似
 : 印象中smol性能最好,tokio最易用,应该都可以参考
 : ...................
 --
 FROM 221.216.116.*
 
- 只要是非实时系统,大概就都不行,换成C和C++更难搞定
 一次消息16KB,相邻两次消息间隔不定,最长约100us,最短约4~5us
 用异步任务就会经常错过下一次消息,总怀疑是异步运行时的问题,而且怀疑异步IO会频繁触发系统调用,导致内核态/用户态切换,存在一个不确定开销。 不知道怀疑的点是否合适
 
 【 在 chunhui 的大作中提到: 】
 : 我去看看
 : 你这种实时性要求高的,貌似rust这种没有实时抢占全靠自觉放弃cpu的合作多任务比较麻烦。
 --
 修改:AlphaO FROM 1.202.157.*
 FROM 1.202.157.*
 
- 正在执行的其他任务不能保证及时释放cpu。得一直等到当前任务完成,运行时才有机会去执行到来的消息。如果当前任务消耗时间超过100us。那肯定会丢消息。 或者说不需要当前任务时间长,只要它正赶上消息到来的时间没处理完,那就会丢消息。 
 
 可以考虑轮询消息?这样会浪费cpu。
 【 在 AlphaO 的大作中提到: 】
 : 只要是非实时系统,大概就都不行,换成C和C++更难搞定
 : 一次消息16KB,相邻两次消息间隔不定,最长约100us,最短约4~5us
 : 用异步任务就会经常错过下一次消息,总怀疑是异步运行时的问题,而且怀疑异步IO会频繁触发系统调用,导致内核态/用户态切换,存在一个不确定开销。 不知道怀疑的点是否合适
 : ...................
 --
 FROM 125.34.113.*
 
- 将处理消息任务和接收消息暂存任务分开,是否能解决丢失消息的问题?
 既然处理消息的时长不定,就只能先暂存消息了。
 
 
 【 在 AlphaO 的大作中提到: 】
 : 只要是非实时系统,大概就都不行,换成C和C++更难搞定
 : 一次消息16KB,相邻两次消息间隔不定,最长约100us,最短约4~5us
 : 用异步任务就会经常错过下一次消息,总怀疑是异步运行时的问题,而且怀疑异步IO会频繁触发系统调用,导致内核态/用户态切换,存在一个不确定开销。 不知道怀疑的点是否合适
 : ...................
 --
 FROM 223.72.108.*
 
- 嗯,已经是分离的架构,类似下面语句不断循环
 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.*