Message135079
# A lock taken from the current thread should stay taken in the
# child process.
Note that I'm not sure of how to implement this.
After a fork, even releasing the lock can be unsafe, it must be re-initialized, see following comment in glibc's malloc implementation:
/* In NPTL, unlocking a mutex in the child process after a
fork() is currently unsafe, whereas re-initializing it is safe and
does not leak resources. Therefore, a special atfork handler is
installed for the child. */
Note that this means that even the current code allocating new locks after fork (in Lib/threading.py, _after_fork and _reset_internal_locks) is unsafe, because the old locks will be deallocated, and the lock deallocation tries to acquire and release the lock before destroying it (in issue #11148 the OP experienced a segfault on OS-X when locking a mutex, but I'm not sure of the exact context).
Also, this would imply keeping track of the thread currently owning the lock, and doesn't match the typical pthread_atfork idiom (acquire locks just before fork, release just after in parent and child, or just reinit them in the child process)
Finally, IMHO, forking while holding a lock and expecting it to be usable after fork doesn't make much sense, since a lock is acquired by a thread, and this threads doesn't exist in the child process. It's explicitely described as "undefined" by POSIX, see http://pubs.opengroup.org/onlinepubs/007908799/xsh/sem_init.html :
"""
The use of the semaphore by threads other than those created in the same process is undefined.
"""
So I'm not sure whether it's feasable/wise to provide such a guarantee. |
|
Date |
User |
Action |
Args |
2011-05-03 21:39:58 | neologix | set | recipients:
+ neologix, gregory.p.smith, pitrou, bobbyi |
2011-05-03 21:39:57 | neologix | set | messageid: <1304458797.39.0.439682215209.issue6721@psf.upfronthosting.co.za> |
2011-05-03 21:39:56 | neologix | link | issue6721 messages |
2011-05-03 21:39:56 | neologix | create | |
|