Antoine Pitrou <pit...@free.fr> added the comment: Thanks for the explanations. This sounds like an interesting path.
> Each thread implementation (thread_pthread.h, thread_nt.h) > would provide a new PyThread_reinit_lock function that would do the > right thing (pthread_mutex_destroy/init, sem_destroy/init, etc). > Modules/threadmodule.c would provide a new PyThread_ReInitLocks that > would walk through the linked list and call PyThread_reinit_lock for > each lock. Actually, I think the issue is POSIX-specific: Windows has no fork(), and we don't care about other platforms anymore (they are, are being, or will be soon deprecated). It means only the POSIX implementation needs to register its locks in a linked list. > But this wouldn't allow a lock's state to be inherited across fork for > the main thread (but like I said, I don't think that this makes much > sense anyway, and to my knowledge no implementation makes such a > guarantee - and definitely not POSIX). Well, the big difference between Python locks and POSIX mutexes is that Python locks can be released from another thread. They're a kind of trivial semaphore really, and this makes them usable for other purpose than mutual exclusion (you can e.g. use a lock as a simple event by blocking on a second acquire() until another thread calls release()). But even though we might not be "fixing" arbitrary Python code automatically, fixing the interpreter's internal locks (especially the IO locks) would be great already. (we could also imagine that the creator of the lock decides whether it should get reinitialized after fork) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
