Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Actually, my approach was not 100% correct, it failed in some rare cases. I've come to the conclusion that using an unlock count on the PyFileObject is the correct way to proceed. I'm now attaching a working and complete patch which protects all methods of the PyFileObject. The original test suite runs fine, as well as the added test cases and Tim Peters' crasher here: http://mail.python.org/pipermail/python-dev/2003-June/036537.html
To sum up the changes brought by this patch: - no supplementary locking - but each time we release the GIL to do an operation on a FILE, we increase a dedicated counter on the PyFileObject - when close()ing a PyFileObject, if the aforementioned counter is non-zero, we throw an IOError rather than risking calling fclose(). By construction this cannot happen in the PyFileObject destructor, but if ever it happens (for example if a C extension decides to put its hands in the PyFileObject struct), we throw a SystemError instead. Added file: http://bugs.python.org/file9894/filethread3.patch ____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue815646> ____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
