New submission from Kushal Kumaran <[email protected]>:
If a process holding a multiprocessing.Lock dies, other waiters on the lock
will be stuck. This is mostly the same as with threads, but threads-users can
usually avoid this with careful coding (dealing with errors, etc.), and
significant crashes will normally take down the entire process anyway. With
multiprocessing, a process with lock held could get SIGKILLed with no recourse.
A simple program demonstrating the problem:
```
import multiprocessing
import os
import signal
lk = multiprocessing.Lock()
def f():
my_pid = os.getpid()
print("PID {} going to wait".format(my_pid))
with lk:
print("PID {} got the lock".format(my_pid))
os.kill(my_pid, signal.SIGKILL)
if __name__ == '__main__':
for i in range(5):
multiprocessing.Process(target=f).start()
```
Running this will have one of the processes acquiring the lock and dying; the
other processes will wait forever.
The reason behind this behavior is obvious from the implementation that uses
POSIX semaphores (I don't know how the win32 implementation behaves).
I don't think the behavior can be changed, since releasing the lock on process
crash could leave other processes having to deal with unexpected state. A note
in the documentation for the multiprocessing module is all I could think of. I
don't see a way to use multiprocessing.Lock with safety against process
crashes. If someone has a scenario where they can guarantee their data
consistency in the face of process crash, they should use some alternative
mechanism such as file-based locking.
----------
components: Library (Lib)
messages: 393695
nosy: kushal-kumaran
priority: normal
severity: normal
status: open
title: multiprocessing documentation should note behavior when process with
Lock dies
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue44138>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
