conditional variable + pthread_kill?

只有 thread a 可以改那个 thread variable，其他 thread 执行完了，等那个 conditional variable

pthread_kill 干掉执行一半的 thread。

假设 A 先执行完，那么其他线程就立即结束

这句话我没理解。。。是说 B，C 先执行完的话，要等 A？没先执行完，就要被马上中断？

想为 user level thread 实现抢占式调度，应该有不少办法。

user-programmable schedulers

Kostis Kaffes Syrup: User-Defined Scheduling Across the Stack. SOSP ’21.

Towards User-Programmable Schedulers in the Operating System Kernel https://www.pure.ed.ac.uk/ws/files/265136338/Towards_User_MVONDO_DOA04032022_AFV.pdf

没具体看，似乎是相关的东西。

Andrew Huberman 的 podcast 挺有意思的，neuroscientist，讲 neuroscience 相关的知识，可以在油管上搜。

人是会成长的。

刚开始学写代码，有可能会觉得，Ruby 这么写可以，那么写可以，真神奇。写多了，发现状态，继承确实让代码少了，但直观吗？再然后，可能会发现，代码整体的合理，比局部的简洁重要。之后是设计，做什么，不做什么，让哪个服务/部分做，设计好了，如何描述，问题都不大。

对我个人来说，最大的好处是逼迫我把问题想清楚。想不清楚，肯定写不出来。当然也有别的方法，比如和人讨论。

再一个是反应技术能力。我面试过的人中，有两位本来面试表现的并不好（只是表现不好），我犹豫要不要 fail，但发现文章写得不错，最后就通过了。

全栈的里面目前来说最优的

额……你要想说 hotwire 好，需要对比类似的技术方案，以及对比前后分离的方案，还有这个技术的试用范围。

如果是喜好，自己喜欢就好，喜欢什么好，大可不必让别人认同你。

你认为好的东西，别人可能连了解的想法都没有，但这并不影响你喜欢。

但要想让别人认同，就需要给分析了。

我没用过 hotwire，对这个技术也没做过研究，所以没有办法对此给出任何评价。

前端可能有自己的想法，有可能是觉得难，或者觉得没有学习的必要。不过这个还是前端来说比较好。

总结下来是不是

1. Hotwire 依赖 DOM HTML，对新时代前端不友好
2. 导致上手成本高

感觉楼主可以展开说说。

Rails 的开发者多数是后端或者是全栈，所以他们看问题，多数是从后端或者全栈的角度来看的。

但前端有前端看问题的角度和方法。所以具体聊聊，可能会很有意思。

评价一个事物，需要跳出来看看。比如西瓜好吃，那需要尝尝几种其他水果，甚至是和蔬菜，肉对比一下。

棒棒棒

我们有一个项目，原来是用 Erlang 写的，打算用 Rust 重写。还没重写完，tokio 就升级了。。。

Erlang 这段时间，做了一些优化，扛住了并发，稳如老狗。

可能看看 tokio 的 example，看看 match 会好一些。

如果一个人用工作时长的一半就完成了他的工作，剩下的时间他选择阳光海滩。而另一个人每天加班加点，超时工作才能把事情做完，果断给第一个人加工资。

软件开发，工作完成，很难界定。比如一个东西，修修补补就 30 分钟，但要是考虑合理行，就要几个小时。

再比如文档，写文档会花很多时间，还不一定算在产出里。

Redis 单线程，首先是因为他是内存型的（Redis 落盘默认也不是每次都落），内存操作比较快，多线程要考虑锁，锁冲突，编程难度大。所以做人认为多线程可以。这种玩法，是很久以前的玩法。

不少 key value storage 是用多线程，比如 Erlang 的 ETS，可以跑满 60 几核，可以随着 cpu 核心数横向扩展，是一个比较有意思的事情。但实际工业上，多数靠集群抗，再加上有 docker。Reids 5 的一般上限制是 5w ~ 6w qps，不少应用，都到不了这个 qps。所以，单核就单核吧。

多说一嘴，in memory 的 key value 瓶颈可能也不在 cpu 那，在网络协议。

大佬，听说你们公司还在招 Ruby？都有什么要求啊？

这个工具是否有用，要看项目的复杂程度，简单的项目用处不大，但复杂的项目就有帮助了。

之前有次 ES 负载不均，搜索服务一直报错，用户开始反馈，更尴尬的是没熔断。搜索团队给了各种建议。我们的负责人（业务网关在我们这）说，把这个功能去掉，上线。。。去掉了一个月，也没有用户发现。

大佬带带我

架构设计，log，监控，压测，灰度方案，回滚方案，限流，降级方案，扩容方案。

除了架构设计，基础服务好的话，做起来很方便，没有的话，就很麻烦。

感谢，已更新。

来呀～～～

有个研究数据库的人参加 大数据大会，他说他非常高兴，终于知道自己这四十年来，研究的叫什么了。

还有写相关的，比如红蓝黄。再比如疫苗，再比如奶粉。再比如三鹿 http://finance.people.com.cn/n/2014/0812/c66323-25446708.html

多看看新闻联播心情就好了。

https://mp.weixin.qq.com/s/sqFkBEIMhKlMuvvhMPnTTg

聊到 Large Scale 的时候，还盯着 web server 的话，就特没啥意思。。。

现在招聘计划有变，我先问问他们。

我们就叫 crypto.com