Welcome to the Black Parade

梓瑶在上周分享的 rust x SIGPIPE 的 issue 很有意思： https://t.me/ziyao233channel/3879 issue: https://github.com/rust-lang/rust/issues/62569 这里涉及了命令行软件和服务端软件的一些默认实践，我翻了一下几年前的笔记恢复了记忆。 服务端软件（socket 网络编程）通过 write (writev/sendto/sendmsg/sendmmsg) syscall 发送 tcp 流量，这里有个几乎无法避免的情况是，进程正在 write(sock)，对端的 tcp reset 飞过来了，内核会抛出 SIGPIPE 信号通知进程这个 socket 不可写。 这个行为对于服务端软件是完全有害且多余。 - 说有害是因为 SIGPIPE 信号的默认处理是崩掉进程，然而 socket 收到 tcp reset 本来就是预期之内的情况，所以必须忽视 SIGPIPE。 - 说多余是因为忽视 SIGPIPE 之后，write syscall 返回 EPIPE 错误码，进程不可能错过这个报错，“正在给一个已经收到 tcp reset 的 socket 写数据” 的这个信息量没有得到任何丢失，反而由于同步化的 EPIPE 返回简化了信号处理（否则 pthread_sigmask + sigtimedwait 是有多想不开） 因此写网络程序直接 ignore SIGPIPE 百利无害，此事在 Unix Network Programming 中亦有记载，UNP 还是太权威了[1] 既然如此那为何要设计 SIGPIPE，全部用 EPIPE 错误码不就好了？答：unix 历史遗留 https://stackoverflow.com/questions/8369506/why-does-sigpipe-exist 这里带出了 SIGPIPE 的（几乎唯一？）需要抛出的场景，考虑命令行： $ (echo 1; sleep 1; echo 2) | head -1 1 ~ $ echo "${PIPESTATUS[@]}" 141 0 管道下游的 head -1 读到第一个 echo 1 的输出就退出进程了，关闭了 pipe_r，导致 pipe_w 不可写，上游的 echo 2 再 write(pipe_w) 的时候会遭遇 SIGPIPE 中止进程。 古典的 unix 命令行要求此时在 retval 里反映信号，141 == 128 + SIGPIPE(13)。 这个要求导致我们不能无脑 ignore SIGPIPE，否则看起来有点业余。（当然可以在命令行软件里看到 EPIPE 再手动 raise SIGPIPE / return 141😀） 所以 rust 目前默认 ignore SIGPIPE 就常常会使 rust 编写的命令行工具在本应该返回 141 return code 时候返回 0（again，这是可以仔细处理好的：在 EPIPE 时 return 141😀） 如果去看下 go 是怎么处理的，会发现它（貌似）更智慧一点： A write to a broken pipe on file descriptors 1 or 2 (standard output or standard error) will cause the program to exit with a SIGPIPE signal. A write to a broken pipe on some other file descriptor will take no action on the SIGPIPE signal, and the write will fail with a syscall.EPIPE error. https://pkg.go.dev/os/signal#hdr-SIGPIPE 更能照顾到绝大多数场景。 不过在 gdb 调试 go 进程时，由于 SIGPIPE 没有被 ignore，会触发 ptrace 的 signal-delivery-stop，很烦，但都是非常细微的 debugger 细节，正常人类不用管。。。 [1] https://flylib.com/books/en/3.225.1.83/1/ （再不分享点技术内容就要沦陷为飞升为男同🏳️‍🌈交友频道了）

我已经对着屏幕摆出不耐烦的脸了，你要不要看看自己在说甚？大学二年级的知识能不能不要在这胡说啊啊啊啊🤬💊 mov $0xffffffffffffffff,%rdi lock xadd %rdi,(%好感度)

被杰尼龟安利 AI 音乐，这首 suno v5 的 funk 改编简直飞天了🏀 在床上转起来了！

有点受不了被人叫“xx工”，土木工程ptsd，正义纠正同事，请叫我暴龙兽。

我怎么又在做 slides，太沉闷了，好想发疯发裸照，啊啊啊啊🤬

乱点进一位频道主的博客，气质好像我曾经最爱的 eeex（确定不是他本人），“把看地图当成休闲活动之一” 这个特征很明显了，请当作赞美吧😄 我一直想像他那样直言不讳地写出心中的批判，虽然随着年龄渐长，价值观内化对自我性格的改造导致对外界有更加严厉的眼光，但社会化也让我更加谨慎地表达真实价值观，带头欢呼就行了我管你这那的。然而“展真实自我，拍正版GV”才是我最想做的啊！ “到最后，最有理的其实是探索和创造。” “要创造。”

最近 gpt-5.1 是咋了，刚才一个很简单的技术会话给我完全错误的回答。 刚才我问它，如果一个 tcp socket 收到 rst，内核会不会扔掉在 socket recv buf 里已经 acked 但还未被 recv(2)-ed 的数据，它十分自信地说 rst 会让内核直接清除 socket，这是写进 RFC 的。我不信，我连续反问了两次让它仔细想想，读读代码，写个代码测试一下，它还是坚信 rst 会清除 socket recv buf。然后我自己写了一下代码， server import socket, time s = socket.socket() s.bind(("127.0.0.1", 9999)) s.listen(1) conn, addr = s.accept() time.sleep(1) print(conn.recv(4096)) conn.close() client import socket, struct c = socket.socket(socket.AF_INET, socket.SOCK_STREAM) c.connect(("127.0.0.1", 9999)) c.send(b"A" * 100) c.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0)) c.close() server 端果然可以在 rst 之后继续 recv😀 chat link: https://chatgpt.com/share/69169450-f5e4-8006-97dd-008f3ae21672 是它一直错得这么离谱还是最近变得更离谱了？ （睡眠严重不足的起床气，起床先对 AI 发脾气，新时代愤青🤬）

有个对 AI 不满意的点是，就算我问的问题完全错误，它妈都能给我头头是道写个几千字，如果人类并非领域专家绝对被糊弄死。。。 我让 codex 自己动起来做 perf topdown 分析，然后它发现 cpu_core/topdown-fetch-lat/ 在 atomic.AddUint64 + 无 cacheline padding 的时候很高。这个发现挺好的，因为 TopdownL3 输出几百行，我一般只看几行主要 metrics 而不看 breakdown 所以从来没有注意到。我问 codex 为什么 topdown-fetch-lat 很高，这不是 frontend latency 吗，而 cacheline-exclusive stall 显然是 backend stall。 然后 codex (gpt-5-codex) 开始背诵名词了，欣赏一下 On Intel’s Topdown model, “frontend latency” isn’t limited to the I-cache hardware—it buckets any cycles where the backend wants μops but the core can’t deliver them because they were dropped, replayed, or never issued. In nopad atom, each atomic.AddUint64 repeatedly loses the cache line mid-flight: the load succeeds on one core, but before the RMW completes, another core grabs exclusive ownership, forcing a pipeline flush and μop replay. Intel counts those μop replays in the frontend-latency bucket (topdown-fetch-lat) because the frontend must re-deliver the same μops after the backend abandons the current ones. 我是因为那句 “before the RMW completes, another core grabs exclusive ownership, forcing a pipeline flush and μop replay” 产生怀疑，atomic.AddUint64 (lock prefix insn) 不是会 stall 等待吗，怎么又开始 pipeline flush 了？ 所以我复制 gpt-5-codex 这个回复去问 chatgpt-5.1： is the following statement correct? 果然 chatgpt-5.1 开始痛批这个说法，逐字逐句反驳。 好了现在你手上有两个领域专家给出相反的意见，你是 tech lead，请做技术决策吧。😀 高潮来了，我重新设置了一下 codex model (gpt-5-codex -> gpt-5-high)，让 codex 重新解释 why "nopad noatom" showed much higher cpu_core/topdown-fetch-lat/ than "nopad atom"? 高潮点是 我tm太粗心，完全问反问题了，明明是 atom 的 fetch-lat 高，我问的是为什么 nonatom 高。😀先问是不是，再问为什么——知乎 然而 codex (gpt-5-high) 居然又给了一篇头头是道的长篇解释，我都看笑了，合着正话反话你都说完了，两难自解是吧。画风是这样的，大部分非专家多半会被唬住： Net: topdown-fetch-lat can be elevated not only by I-cache/ITLB misses but also by frontend re-steers after Machine Clears. In nopad noatom, false sharing + races cause more of those clears; atomics remove the mis-speculation and move the cost squarely into backend memory stalls. 还好我立刻发现自己问题问反了，让它重新检查之后，终于给出一个似乎合理的解释。 用 AI 学习新知识实在太难了，就算是十句里只夹一句假话，产生的误导也破坏力很强，我还是好好看书看文档吧。。。

https://open.spotify.com/album/4ANSdhjb0b1KqKpPTyUSV9 Spotify 终！于！上架了麦当娜二十年前的专辑《Confession On A Dance Floor》的 non-stop 版本😭这么多年我是怎么过来的啊aaa啊啊啊 Non-stop album （连专？）是指一张专辑的音乐之间无缝切换，并无明显的分隔，如果很熟悉披头士的《Sgt. Pepper's Lonely Hearts Club Band》，其中的第一首和第二首就是用的这个技巧过渡；频道名引用的专辑《The Black Parade》第一首和第二首也是如此。麦当娜的《Confession》则是整张专辑全部一致连续，非常有趣，我在2017年之前循环了几百遍这张专辑之后我的音道已无法接受非连续版，但 spotify 只有非连续（不用 Apple Music😀），导致我已经很多年没有循环这张专辑了😭 专辑名 Confession On A Dance Floor 的双关就非常妙，confession 既有“忏悔”的意思也有“表白”的意思，无论哪个意思搭配上“舞池” dance floor 都会产生全新的内核指向，在舞池里的忏悔当然不会虔诚而是反叛，在舞池里的表白当然狂热又狂野，双关之后的精神内核居然又统一起来，太妙了！ 更锦上添花的是专辑发售后一年的 Confession Tour 全球巡演，在我心中是麦当娜排名第一的巡演，开场从迪斯科球里从天而降然后开始鞭打肌肉男 + 《Future Lovers》 + 《I Feel Love》 （Donna Summer，迪斯科女王，《Hot Stuff》）永远在我心中是最佳开场，完爆_______等😀 Madonna - Future Lovers / I Feel Love (Live from The Confessions Tour): https://www.youtube.com/watch?v=n80QXNRIV6c 不过其实和我建立最深共鸣的却是一首非热门单曲《Jump》，我很喜欢那种自由又恐惧、却充满勇气往前的气质： Are you ready to jump? Get ready to jump Don't ever look back, oh baby Yes, I'm ready to jump, just take my hand Get ready to jump （genre: synth-pop，原来我一直最喜欢合成器，时间线闭合了） 著名作词人林夕在 2006 年接受采访的时候把麦当娜这张专辑列为他最推荐的四张专辑之一 [1]，虽然音乐是很主观的事情，但足以说明制作质量。 [1] https://orientaldaily.on.cc/archive/20060125/fea/fea_v4cnt.html

猴子随机打字 6.17 有 bpf_strstr kfunc (https://docs.ebpf.io/linux/kfuncs/bpf_strstr/) ，好想要，想要得不得了🥴😭 不然在 6.1.153-175.280.amzn2023.aarch64 表演现场编译 kfunc 太马戏团了😀 看 IceCode 吐槽 nerdctl 难用 (https://t.me/xixihealth/17666) ，我亲自试了一下，发现不同网桥不互通单纯是有 iptables 规则扔掉了跨网桥流量，手动删除就通了。但 nerdctl 太执着于“完全用 CNI 操作网络”，明明可以手动删除了事，非要让 CNI 支持一个 option 再配置 CNI 来实现。我其实也想革了 dockerd 的命，但 nerdctl 这保守的姿态，不肯把手弄脏，就别指望它能实现 docker network connect 了。（狂妄的内心：能有多难，nsenter 运行 cni add 不就行了😤） update: containerd maintainer 为 nerdctl networking 指明方向： https://t.me/ManjusakaH/606 bpf ringbuf 最佳实践：reserve + NO_WAKEUP，在用户态 SetDeadline 轮询，能极大降低 CPU (user -80%，kern -50%)。（做好丢包统计） cilium/ebpf 观测性项目最佳实践：二次 exec 把 BTF 内存全部清理再从 bpffs 把 pinned map 加载回来，内存直降 30M😃 bpf prog perf🤬 猴子打字！ 原来只有 swich-case 会被 clang 编译成 binary search tree，等价 if-else 只会生成线性决策树。当然最好的办法还是 tailcall 直接 o(1)，但是 load time 会直线上升，只能妥协一下。 Manjusaka 老师长得好像小火龙。 辐射3 remaster in 2026！🩸 (辐射4 周年版烂爆了😀 谁是垃圾 谁不舍我难过 分一丁目赠我😭

正儿八经再来给我司招点人 关键词：AIGC/二次元/行业 Top/超高速发展/Remote 工作 我们目前来说，招聘的岗位有全栈/后端/前端-有seo 经验/搜推算法/推理加速/MLE/ML Data 我司目前出于一个超高速发展的阶段，但是我们在超高速发展的同时保证了一个良性不卷的氛围。我们鼓励大家能高效的完成事情而不是无效的内卷。 在超高速的发展的时候，意味着你有很多的活可以去做。这也意味着你会犯很多的错。 而我司一直秉持的一个观点是，宁可做错事，也不要不做事。 所以我们一直鼓励大家多做，在犯错中成长。 在今天我主持全体10月的复盘会的时候的，我也会在会议开始给大家说清楚，我们 challenge 的永远是事。而不是具体的人 与此同时，我们会非常愿意去讨论一个候选人的潜力与未来价值，同时愿意给大家放权放资源去做事 而公司其余的氛围就非常的好。大家都是年轻人。举个例子就是今年在我猫过世那段时间，我司很多同事都去给我买手办，在我通宵陪护的时候给我陪聊 etc. 至少我对这里有很强的归属感 至于待遇问题，我现在没法给出一个通用的结论，但是用一个比较好具现化的例子来说就是我们能对标阿里同 Level 的薪资还是没有问题。 如果你最近恰好有想看机会的想法，而且你对 AIGC 这个赛道感兴趣。那么欢迎你和我聊聊([email protected])，我请你一杯咖啡

https://lwn.net/Articles/1044844/ 很多年前我在北京写 Python，某个NLP算法业务经常在启动时oom killed。当时我最爱的同事侯老师查了一阵发现是 import jieba 和某个初始化峰值叠加会炸掉内存，解决办法是手动延迟 import jiba 让两个过程错峰，朴素的工程美。 转眼八年过去了，连 Python 都支持 lazy import jiba了，我还在偶尔怀念那些年在北京，虽然那时菜得要死，debug 只会 strace 和 pdb 两招被侯老师批评不认真读代码，可现在的我感觉却是那么悲伤，岁月留给我太深的迷惘。