[issue815646] thread unsafe file objects cause crash

Antoine Pitrou report at bugs.python.org
Sat Mar 29 20:39:34 CET 2008


Antoine Pitrou <pitrou at free.fr> 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 <report at bugs.python.org>
<http://bugs.python.org/issue815646>
____________________________________


More information about the Python-bugs-list mailing list