嘿，HN！
我一直在研究一些可能改变我们对多线程思考方式的东西。<p>你可能还记得 W++——这是我最初在 .NET 上构建的一个混乱的脚本语言。
现在，我已经用 Rust + LLVM 从头重写了它，并意外发明了一些新东西：
一个用于线程的垃圾回收器。<p>W++ 不再将操作系统线程留给手动管理，而是将它们视为堆对象。
它们是引用计数的，会被清扫，并安全地清理——就像其他任何 GC 值一样。<p>亮点：
• 线程通过 `Arc` + `Weak` 管理，并由后台守护进程收集
• 如果拥有线程死亡，`GcMutex` 会自动解锁
• 线程祖先追踪防止递归生成
• 后台 GC 线程定期加入已完成的线程
• 所有编译为本地 LLVM IR——无需虚拟机<p>结果是什么？
没有僵尸线程，没有超出其拥有者的死锁，也无需手动连接。<p>这还是实验性的，尚不完美——但它确实有效。
如果你之前构建过运行时或 GC，我很想听听你的想法。<p>GitHub: <a href="https://github.com/sinisterMage/WPlusPlus" rel="nofollow">https://github.com/sinisterMage/WPlusPlus</a>
欢迎反馈、批评或“你疯了，但我喜欢”的评论！
返回首页
最新
您在荷兰的人工智能火车旅行助手。
Apicat 是终极的离线 Postman 替代品，能够将您的 .http 文件本地存储。它支持 Git，开源，并且与 Postman 兼容性极高。这个强大的免费离线 API 客户端专为需要可靠本地 API 测试工具的开发者设计，可以离线测试 API。
在将Django投入生产的十年后，我厌倦了在每个新项目上解决相同的设置问题。
环境优先的配置。合理的身份验证默认值。结构化日志记录。从第一天起就有持续集成。预提交钩子。Docker。安全加固。每个项目都意味着在编写业务逻辑之前需要花费两天的模板工作。
因此，我构建了Django Keel：一个生产就绪的Django启动项目，消除了繁琐的准备工作。
GitHub: [https://github.com/CuriousLearner/django-keel](https://github.com/CuriousLearner/django-keel)
*你将获得*：
- 基于环境的12因素配置和秘密管理
- 经过生产加固的安全默认设置
- 预配置的代码检查、格式化、测试和预提交钩子
- 随时可用的持续集成工作流
- 清晰的项目结构，便于扩展
- 详细的文档，解释真实的权衡
*背景*：
我多年来维护了一个流行的cookiecutter模板。Django Keel是从一开始就应该具备的——经过实战检验的模式，没有累积的冗余。
*适用对象*：
希望在生产中使用Django的团队和个人开发者，他们想要一个强大的基础而不想承担技术债务。
欢迎反馈哪些方面有效，哪些无效，以及缺少什么。感谢提出问题和拉取请求。