没有目的读是很难读的

...不熟悉 python 还不装 ide... 你开心就好

搜索 location 优先级啊

=规则优先级最高


还满足不了你的话 上 openresty 咯

@inoizyz
就是就是 哈哈哈哈

话说...好像这些都是从 erlang 里出来的？

@richzhu

记这个不如好好把一个协程库的代码读透,比如 python 的 eventlet
读透了搞清楚模型模型了就自然理解了....啥语言都一个样,记下来真没用....

线程
一个线程跑满,就吃饱一个 cpu
N 个线程跑满对应 N 个 cpu,只要与 cpu 数量相同多线程就能吃饱 cpu
但是实际代码里会阻塞,一阻塞会自动让出 cpu, 所以在阻塞写法里,程序的线程超过 cpu 数量能提高性能
但是过多的线程数带来的上下文切换回拖慢整体


协程
通过寄存器保存代码片段,遇到阻塞（一般是 io,或者自定义的协程锁)，会切换到其他代码片段
所有代码片段的入口存放一个不停排序的队列
一个循环（相当于一个线程）不停的排序这个队列,并弹出最前面的数据获取到代码片段并执行
一般只有一个主线程,由于代码片段的切换由程序自己决定,没有系统级上下文切换,性能好,缺点是单线程


所以性能最好的方式是结合多线程与协程,但是非语言级很难用一个库来实现支持多线程的协程

目前除了 go, dart （也就是 google 的 flutter 所用语言）也有多线程协程支持


我瞎鸡巴说的...我没写过 go 哈哈哈哈哈哈

我用到 openstack 的 oovo
我想支持多个数据库（拆分日志库,业务数据库）
具体就不细说了


现在的是改造
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/db/api.py
的 event.listens_for 部分

因为他的代码里不需要支持多个数据库,所以_emit_on_pending 是个单独的

因为我有多个库, 所以需要通过不同的 declarative base （不同数据库的表继承不同的 declarative base ）反馈返回不同的_emit_on_pending

如果用 session 来区分,下面这种没 session 的监听就不好处理
@event.listens_for(model_base.BASEV2, "attribute_instrument", propagate=True)

所以我需要 db object 里获取到对应的 declarative base,但是不是很想通过 mro

好像用 obj.__class__.metadata is not BASEV2.metadata: 这种方式也行

我想从一个 db object 的属性里找到他的 declarative base 对象
从而分辨这个 db object 是哪个数据库连接的

应该可用 obj.__class__.__mro__[1] is DBBASE 来确定这个 db object 的 declarative base
但是我不太想用 mro.....因为不是那么熟

搞不定 最后只能用 metadata 来判断

if obj.__class__.metadata is not DBBASE.metadata:
return

是进程肯定不干净

没有区别, posix_spawn 就是 fork+exec,以前没有 posix_spawn 系统调用而已

搞清楚了原理,自然知道如何避免 celery 有可能带来的负面影响

multiprocessing 本来就是就是单次脚本中让你快速多进程跑代码的库,自己里面生线程还有管道 /socket 通信,里面不说多复杂但进程肯定干净,混合到复杂代码里基础不牢问题都不知道出哪,本来就不适合用到服务中。
特别是 multiprocessing 进程池中可复用的进程除非你能确定进程不被污染,否则跑起来就是自己找坑。

所以我早说了, 对于不熟悉 linux 编程也不想读 multiprocessing 源码的同学, 稍微复杂一点的代码都不要使用 multiprocessing。

无论什么扩展,最后都是要 fork

搞清楚多进程知识以后, 是不是 celery 都没关系,知道什么时候退出,什么时候回收就是

哪有那么麻烦, 只要你处理好异常,os._exit 的时候我管你是 celery 还是 flask 还是 dj

你的快速方法明显是不对的

学习的时候遇到深度问题如果超过能力或者没有必要的确需要跳过,但是非常基础的问题习惯性跳过是不行的

多进程问题是非常基础也常用的知识,只要你用到多进程就会遇到相关问题,这次绕圈解决了下次一样有问题解决不了
老老实实把坑填了用的时间比这次绕圈解决长一点,但是你淌过去了以后就解决起其他多进程问题就有底了

python 残疾的多线程是必须多进程的,不搞懂以后坑的是自己

好好学习下 linux 这部分基础知识真不需要那多时间的

先看信号
https://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html

再看僵尸进程
https://monkeysayhi.github.io/2018/12/05/%E6%B5%85%E8%B0%88Linux%E5%83%B5%E5%B0%B8%E8%BF%9B%E7%A8%8B%E4%B8%8E%E5%AD%A4%E5%84%BF%E8%BF%9B%E7%A8%8B/


最好把 ibm 文档理进程间通信都好好看一便,认真看多看几遍,看明白了,想明白了,再回头看你刚才帖子说“我知道的”部分是哪里错了,好好了解下父子进程共享了什么东西会导致什么问题

基础打牢了很多问题就解决了.真的不难,没搞清楚只能瞎问

后面可以 subprocess 的源码熟悉进程间通信和 fd 关闭在 python 的写法和处理方式
然后把 https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py 的代码读透
然后有需要可以读下 multiprocessing 的源码,不需要通读你有上面的知识大致接到 multiprocessing 如何工作的即可

之后你不需要论坛理问什么 celery 多进程的问题了,搞懂原理了才能真正解决问题,因为这些问题都不是 python 的问题都是系统原理性问题

这么说吧, multiprocessing 没有问题,你知道原因根本不用 patch

spwan 也就是是 fork exec 了一个新 python 进程专门执行部分代码避免当前进程的污染
但是这种绕圈的方式是不合理的和混乱的.

当然你觉得能用就行也无所谓.

都说了, 不熟悉 linux 编程也不想读 multiprocessing 源码的同学, 稍微复杂一点的代码都不要使用 multiprocessing

好好把 linux 相关的父子进程,信号处理学学也就半天时间
回头你再看 multiprocessing 自然知道到底是什么问题,原理不了解和你说也会变更多基础问题疑问

好好学习下 linux 这部分基础知识真不需要那多时间的,论坛反而是浪费时间。

@ytymf
fork 又不是 python 自己的玩意,都说了好好看 linux 编程基础,光看 python 文档搞得清楚个鬼

什么鬼 fork 出来的就变僵尸进程......

你直接问下 常用排序算法的优势和应用呗

比如快速排序用来算 topk

堆排序普遍用于异步队列的排序

都是 linux 编程基础,和 python 关系不大
老老实实去熟悉 fork exec wait 等 linux 编程基础吧,这些基础支持不懂,无论你用什么多进程库都会遇到类似问题。

顺便...对于不熟悉 linux 编程也不想读 multiprocessing 源码的同学, 稍微复杂一点的代码都不要使用 multiprocessing