是进程肯定不干净

没有区别, 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

@Trim21

LOG = logging.getLogger(__name__)

不是所有情况都是走索引比全表扫描快的

python 使用下划线源自于 linux c 代码风格

习惯这种风格以后看 linux 里相关 c 代码比较舒服

请学习并使用 openstack 的 oslo.log

我自己家用的 gitea
数据库用的 PG,很清爽 没有遇到 15 楼的问题

最好不要用 MariaDB, bug 多一点遇到几次了
而且几个流复制工具不支持 MariaDB 只支持 mysql
因为这些流复制工具用的 java 库不支持 MariaDB,难兼容

要抓住重点,池不池不重要,核心是要跑满 cpu
但是要避免线程多了上下问切换是浪费掉的

因为 python 多线程是废的,根本不用考虑多线程, 协程+多进程就是

@Greendays

价格高,性能损失....

但是解决了一个很重要的——环境一致性问题,这点非常适合程序员
而且轻便简洁,但雷蛇显卡坞都要 2200,这只是一个盒子还没算显卡钱
dell TB16 扩展坞洋垃圾都要 800 块

用起来是很爽....就是一套下来贼贵 233
但我觉得花得很值...可惜当时没这本子只能买了 dell 的工作站...这货就是外接了显卡光负载 cpu 都散热都不够给力

@BingoXuan

现在问题在于, 有显卡和没显卡的价格差距不是很大, 用户很容易被独立显卡给蒙蔽了

当然年代不一样了,雷电也普及了很多,我也挺希望这类产品开花的,以前真是想买都没。