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.