crazzy

你问这些问题，大概率证明你思考了，但是却只思考了一点点。我是想回答又不想回答你，但是我既然准备回复你，就不做无意义回复。


进程、线程、协程甚至于 goroutine 都是并发模型，不同的模型因为实现机制不同，在不同的场景下各有优劣，并不是绝对的优劣势。

例如，进程的上下文切换开销大，线程的上下文切换开销小，那么单纯考虑上下文切换开销，我们就选择多线程模型吗？为什么不考虑协程或 goroutine ？

PostgreSQL 选择多进程模型是因为在它最初开始开发的时候，线程在各个操作系统中是一个很新颖的东西，而进程却很成熟了，没得选。

对于数据库这种有很多共享数据的软件，从理论上多线程就比多进程有优势，所以后期很多数据库都是多线程模型。


- 有没有讨论过改、有没有必要改；要学会自己收集信息，邮件列表是公开的，不回答
- 在一定要改动的情况下，必要和非必要、好改和不好改的区分；在你没有阅读过源码、了解其生态的情况下，仅有一个答案有什么意义？不回答
- 改成多线程模型后的收益；这个问题问的，你可能都没有深入的使用过 PostgreSQL ，也不了解并发模型，可能你就是制造一个噱头来提问的吧...

这都是异步，肯定会出现一个请求检查完 isRefreshing 准备赋值前，另一个请求也在检查 isRefreshing 了。

一个异步的整个生命周期中，事件循环会处理其他任务

没喝过径山茶，当个分母

设置 Pull Request 触发的 Action 语法

```yaml
on:
pull_request:
```

还可以具体一点的设置是打开、关闭 PR 的时候触发 https://github.com/DIYgod/RSSHub/blob/master/.github/workflows/lint.yml


---


强制 Action 成功后合并，印象中 GitHub 似乎是没有的，但是 GitLab 有。

不过可以换个思路去理解，有合并权限的基本上都有写权限，既然有写权限，那么就算 CI 不成功他可以直接写进去啊 ;)

GitLab 的权限是比较严格的。针对目录、文件级别的权限，必须要指定哪些人审核了才行，还可以强制指定需要审核同意数量。


---

简而言之就是，如果不是很多人天天专职在一个仓库提交，因为这个浪费的时间很多，没必要折腾这个。等你觉得这是必需品了再去折腾。开源的东西，就 GitHub Action 差不多就够了。

当然也不是没有人觉得不够，他们选择自建 CI/CD ，例如 Kubernetes 就不用 GitHub Action 。但是他们的 CI/CD 是结合 Workflow 的，更进一步。