This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients anthonybaxter, christian.heimes, georg.brandl, jafo, janixia, jhylton, loewis, pitrou, tim.peters
Date 2008-03-29.19:39:28
SpamBayes Score 0.3066053
Marked as misclassified No
Message-id <1206819574.48.0.449446302919.issue815646@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2008-03-29 19:39:35pitrousetspambayes_score: 0.306605 -> 0.3066053
recipients: + pitrou, tim.peters, loewis, jhylton, anthonybaxter, georg.brandl, jafo, janixia, christian.heimes
2008-03-29 19:39:34pitrousetspambayes_score: 0.306605 -> 0.306605
messageid: <1206819574.48.0.449446302919.issue815646@psf.upfronthosting.co.za>
2008-03-29 19:39:33pitroulinkissue815646 messages
2008-03-29 19:39:32pitroucreate