Author neologix
Recipients bobbyi, gregory.p.smith, neologix, pitrou
Date 2011-05-03.21:39:56
SpamBayes Score 1.06271e-12
Marked as misclassified No
Message-id <1304458797.39.0.439682215209.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content
# 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.
History
Date User Action Args
2011-05-03 21:39:58neologixsetrecipients: + neologix, gregory.p.smith, pitrou, bobbyi
2011-05-03 21:39:57neologixsetmessageid: <1304458797.39.0.439682215209.issue6721@psf.upfronthosting.co.za>
2011-05-03 21:39:56neologixlinkissue6721 messages
2011-05-03 21:39:56neologixcreate