兄弟，你这检测办法，笔记本检测一遍，估计得掉 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 。

我之前零刻 eq12 ，安装 pve 慢，然后运行中负载搞了就容易死机。换了内存尝试依旧。后面还了 ssd ，好了。奇怪的是这个 ssd 检测，当移动硬盘什么都正常。

这么说的话，和这个比较像的项目，就是青龙面板，面板核心功能就是定时任务，它可以说连脚本开发文档都没有，但是热度同样很高。我之前发帖，https://www.v2ex.com/t/1016931

@nebkad
@PTLin 感谢 2 位，说明白了

@nebkad 自己实现容易吗？ 主要是好奇，把&mut 搞为&，依然可以执行看起来"改变"的操作。感觉 5 楼的解释比较合理。对于 rust 来说，File 就是不可变的，变的那部分在 os 维护，读取的位置，缓冲区等等。

@nebkad 搞这个&File 可以读取（引起数据改变）操作比较迷惑，给人的感觉就是不可变突然可以变了

@Kaleidopink File 也有实现 Read trait ， 不过实现方式还是用 &File 的实现。 这些其实不是重点，重点是， 为什么读取数据可以是不可变的

外部输入的 sql 参数，不使用预编译参数，不对合法性进行检查，sql 注入了。 这和 mybatis 没什么关系。

个人觉得，这和福利彩票店，各种算，各种画，并没有本质区别