@processzzp 插值不插值 3w dpi 没法正常使用

@shilianmlxg
@jadehare f1 在比赛的场景下，是明显优于五菱宏光的，但是 1w 以上的 dpi 有什么场景的表现能优于 1200 左右 dpi ，我觉得 1w 以上的 dpi ，已经严重影响鼠标的正常使用了

@Hookery 不是电竞选手也很容易发现 1w 以上 dpi 难以驾驭（没法用）

@CSGO
@FishBear 回报率，我测试 1000hz 和 8000hz 感觉不出有什么区别

Cursor 是可以做一些简单的工具，不如计算器，编码转换啥的，但前提是逻辑简单。问一下，Cursor 这种鼓吹文章在哪里可以领钱，我也想领

@liv22 还用问吗，行情好， 闭着眼睛买都赚， 行情不好，巴菲特给你指导都得亏。不用问， 看哪个顺眼买哪个，当然如果你非要算算， 可以用你生辰八字和股票名称算算。不过你要提前考虑好最差的后果， 你是否可以承受， 如果承受不了就不要上赌桌，怎么下注真的不重要

@nyxsonsleep 你告诉我哪一步会当老赖？

兄弟，你这检测办法，笔记本检测一遍，估计得掉 2%的电

如果不想给钱， 想折腾。只要交警判定你有责任，你就不服。申请复核->行政复议 -> 行政诉讼 一圈折腾下来， 半年过去了。 然后判断有责，但是你拒绝赔偿，让他去起诉，判决你输，你就提起上诉，这样折腾一下，最少又半年过去了，过程中对方如果放弃的话，那你就可以不用赔了，可能这些操作花费的时间、金钱还不如直接赔钱。 当然你也可以从拒绝赔偿开始， 对方起诉时候，庭前调解，你就认怂赔钱了事。
如果想省事，那直接赔偿 480 了事。
如果想少赔，假如接受 100 ，那你就直接给他 100 。他要不行，还要剩下的 380 ，你可以不用理他，他只可以起诉你，没别的办法，大多数不会为了 380 块去起诉你。

@fakeshadow 就算嵌入式，不支持 arc ， 那同样也可以屏蔽 split ，嵌入式基本不支持 thread ，那标准库还不是 thread 也提供了，我认为嵌入式场景不是设计成读写一体的主要原因

@fakeshadow 读写在不同线程处理在很多场景都需要啊， 比如代理软件，p2p 共享软件。实现的话， 我能想到的是，ReadStream 和 WriteStream 共同持有底层 fd ， 这个 fd 使用 arc 记录引用次数。当 arc drop 时候，close 掉 fd 。ReadStream 和 WriteStream drop 时候，shutdown 掉对应的 read write

@PTLin 在 c 里面，fd 就是个 int ， 放到 write 和 read 函数都可以， 不管这个 fd 在哪个线程被并发调用，我之前奇怪的是，很多语言，java 、golang 、c 、都可以将读写分开进行处理，rust 这不能分开太难受了，我要实现一个 http proxy ，需要两个 tcpstream 的 读写在两个线程互相 copy ，所以就有了此贴。有了 OwnerTcpStream 方便了很多。
不过个人感觉，标准库，不应该去实现 impl Write for &TcpStream ，而是应该给 tcpstream 提供函数可以获取 ReadStream 和 WriteStream 他们两个持有相同值类型 fd ，这样 api 更为友好。最后感谢各位的回复，谢谢大家🙏

@PTLin 有点理解了， 这里如果不是 impl Write for &TcpStream ，那 arc 就没法实现共享 tcpstream 进行写入，&File 可能也是基于这个和 drop 关闭资源考虑吧

多次尝试，通过 arc 确实可以实现，因为 impl Write for &TcpStream 有一个这样的实现，它就只需要 &TcpStream 的&mut &TcpStream 就可以了，arc 可以提供&TcpStream 的所有权 所以就可以调用到&TcpStream 实现的 write 方法。

实现代码如下

use std::io::{Read, Write};
use std::net::TcpStream;
use std::sync::Arc;

pub struct OwnerWriteTcpStream {
inner:Arc<TcpStream>
}

impl Write for OwnerWriteTcpStream {
fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
(&*self.inner).write(buf)
}

fn flush(&mut self) -> std::io::Result<()> {
(&*self.inner).flush()

}
}

pub struct OwnerReadTcpStream {
inner:Arc<TcpStream>
}

impl Read for OwnerReadTcpStream {
fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> {
(&*self.inner).read(buf)
}
}

pub struct OwnerTcpStream(TcpStream);

impl OwnerTcpStream {
pub fn new(stream:TcpStream) -> Self {
OwnerTcpStream(stream)
}
pub fn split(self) -> (OwnerReadTcpStream, OwnerWriteTcpStream) {
let arc_read=Arc::new(self.0);
let arc_write=arc_read.clone();
let read=OwnerReadTcpStream{inner: arc_read};
let write=OwnerWriteTcpStream{inner: arc_write};
(read,write)
}
}

这个回复 markdown 用不了，不知道为什么

@PTLin 本来读写分开不应该占用两个文件描述符，也不需要 dup syscall 。感觉 safe 代码没法实现读写分开有所有权。参考 @capric 尝试用 Arc<TcpStream> ，但是 Write Trait 的 fn write(&mut self, buf: &[u8]) -> Result<usize>; 需要一个 &mut self ，inner 的 Arc 提供不了可变借用。实现这个分离感觉只能 unsafe 代码

@PTLin
@capric tokio 现在还没用， 不过这个 split 够优雅。 看来这个阻塞 io 下没有一个好的方式来处理这个分离的问题。不知道 tokio split 底层具体实现的原理的是什么

@SingeeKing 一些资料上说，TcpStream try_clone 采用底层操作系统的 dup （在 Unix 上）或 DuplicateHandle （在 Windows 上）来创建一个新的文件描述符，该描述符指向同一个底层套接字，这样会占用一个文件描述符。另外这样调用 try_clone 不够直观。

@nagisaushio BufReader 是没问题，但是 BufWriter 我试了下不行。因为 BufWriter<W: ?Sized + Write> 而 Arc<TcpStream> 没有实现 Write 。arc 套 buf 看起来只能实现 Reader 不能实现 Writer 。