HackerNews中文版

嘿，HN！我一直在研究一些可能改变我们对多线程思考方式的东西。你可能还记得 W++——这是我最初在 .NET 上构建的一个混乱的脚本语言。现在，我已经用 Rust + LLVM 从头重写了它，并意外发明了一些新东西：一个用于线程的垃圾回收器。W++ 不再将操作系统线程留给手动管理，而是将它们视为堆对象。它们是引用计数的，会被清扫，并安全地清理——就像其他任何 GC 值一样。亮点： • 线程通过 `Arc` + `Weak` 管理，并由后台守护进程收集 • 如果拥有线程死亡，`GcMutex` 会自动解锁 • 线程祖先追踪防止递归生成 • 后台 GC 线程定期加入已完成的线程 • 所有编译为本地 LLVM IR——无需虚拟机结果是什么？没有僵尸线程，没有超出其拥有者的死锁，也无需手动连接。这还是实验性的，尚不完美——但它确实有效。如果你之前构建过运行时或 GC，我很想听听你的想法。GitHub: <a href="https://github.com/sinisterMage/WPlusPlus" rel="nofollow">https://github.com/sinisterMage/WPlusPlus</a> 欢迎反馈、批评或“你疯了，但我喜欢”的评论！

查看原文

Hey HN! I’ve been working on something that might change how we think about multithreading.You might remember W++ — a chaotic scripting language I originally built on .NET. Well, I’ve rewritten it from scratch in Rust + LLVM, and accidentally invented something new: a garbage collector for threads.Instead of leaving OS threads to manual management, W++ treats them as heap objects. They’re reference-counted, swept, and safely cleaned up — just like any other GC value.Highlights: • Threads are managed with `Arc` + `Weak` and collected by a background daemon • `GcMutex` auto-unlocks if its owning thread dies • Thread ancestry tracking prevents recursive spawns • A background GC thread periodically joins finished threads • All compiled to native LLVM IR — no VM requiredThe result? No zombie threads, no deadlocks that outlive their owner, and no manual joins.It’s experimental, not perfect — but it works. If you’ve built runtimes or GCs before, I’d love your thoughts.GitHub: <a href="https://github.com/sinisterMage/WPlusPlus" rel="nofollow">https://github.com/sinisterMage/WPlusPlus</a> Feedback, critique, or “you’re insane but I love it” comments welcome!

展示HN：W++ – 垃圾回收线程