Bug report

Given the following situation: You have a Process "a" with two threads ("aa", "ab"). aa is currently creating a shared memory segment and is holding multiprocessing.resource_tracker._resource_tracker._lock for that reason. Note that that lock is not acquired by user code, but deep inside the SharedMemory constructor.

ab now wants to create a second process using the fork method. Process b is created with one thread: bb. As per man fork the thread aa is not duplicated in process b.

If aa now finishes creating its SharedMemory it releases multiprocessing.resource_tracker._resource_tracker._lock. But that lock is only a threading.Lock, which means it is released only in process a. In process b it will not be released. If b now wants to create a SharedMemory object and therefore tries to acquire multiprocessing.resource_tracker._resource_tracker._lock this will take forever, as it will never be free in process b. man fork explicitly mentions that such situations are a potential source of issues.

As this is a race condition there is no minimal, reproducible example I can give.

Possible solutions

One could replace this threading.Lock with a multiprocessing.Lock. Alternatively one could replace that lock with a new one in the child process after a fork. Im not sure about the intended behavior of the resource tracker in such situations.

Your environment

• CPython versions tested on: 3.9, 3.10
• Operating system and architecture: Unix (Arch, Kernel 5.19.7-1)