在子进程中创建sharedMemory所导致的异常

最新推荐文章于 2025-01-23 15:49:02 发布

im_cheer

最新推荐文章于 2025-01-23 15:49:02 发布

阅读量735

点赞数 1

分类专栏： python 文章标签： python

本文链接：https://blog.youkuaiyun.com/im_cheer/article/details/124558190

版权

python 专栏收录该内容

2 篇文章

订阅专栏

为了防止内存泄露，目前的multiprocessing模块，当一个process在创建sharedMemory和semaphore时，如果父进程没有resource tracker,则会创建一个属于本process的resource tracker。

这种pattern会导致一个问题，就是当使用multi process-multi consumer模型的时候，如果没在main process先初始化一个resource tracker，会导致不同的process有不同的tracker。这样会有什么问题呢，我们先看一个例子。

运行这段代码会打印以下信息：

其中resouce tracker的信息是直接修改resource_tracker.py的源代码打印的init_resource tracker + pid 可以看到这里在创建的有2个register_tracker，分别是创建sharedmemory以及使用sharedmemory时所创建的。于是在pool0中创建的shm，会被注册到27385 pid的resource tacker中，而pool中使用和注销的shm，会在27390中操作。

在程序关闭时，resource tracker会检查被register但是没有被unregister的系统资源，并逐一释放，以防止内存泄露。于是在pool中被释放的资源，在pool0中并没有被unregister，因此报了可能存在内存泄露，且尝试释放此资源时，由于已经被pool进程池释放了，导致报错no file ……。

解决方式是，在main process中随意创建并unlink一个shm，使主进程有resource tracker,子进程便会继承这个resource tracker。