> Le lundi 01 février 2010 à 23:58 +0100, "Martin v. Löwis" a écrit : >> Interestingly, the POSIX pthread_atfork documentation defines how you >> are supposed to do that: create an atfork handler set, and acquire all >> mutexes in the prepare handler. Then fork, and have the parent and child >> handlers release the locks. Of course, unless your locks are recursive, >> you still have to know what locks you are already holding. > > So, if we restrict ourselves to Python-level locks (thread.Lock and > thread.RLock), I guess we could just chain them in a doubly-linked list > and add an internal _PyThread_AfterFork() function?
According to the text book, that's not good enough: if some other thread is holding a lock, it's probably because the data structures are inconsistent. If you follow the approach of acquiring all locks before forking, you get more sane data structures in the child processes (in addition to having all locks released). If you would just release the locks in the afterfork function, chances are that something crashes when you next try to access what was protected by the lock. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
